While traveling last month across Europe I’ve very often faced a problem where a public wifi with no password was able to connect but it had no internet access. I am talking places like coffee shops with free wifi or the german rail wifi. it was quite a bummer for me because I had no internet access and apparently others with Android phones or iPhones were able to use the service easily. I am using Samsung GalaxyS9 with latest /e/ OS version and I am happy to debug this and solve it but I would need some guidance as I am not familiar with Android, but otherwise I am a developer with a linux box and adb ready.
I tried restarting and reconncting as well as forgetting those networks but those simple steps did not help ever in cases where the public wifi had a password all worked well.
After connecting to the wifi networks, did you get a notification that you’ve to login into a wifi portal? If yes, did you tap on this notification and login/acknowledge the terms and conditions?
Most of the time I have to use the offered DNS of the public network to get redirected to the accept-terms-page, then the packets of my wifi card get routed to the internet. If I set my own DNS, that sort of thing can’t work. Official public wifis in germany employ this kind of user agreement.
No wifi portal notification I only got notification stating that I am connected but there is no internet.
I assume that there was always a portal behind every such wifi but for some reason it did not direct me that way and I did not know where to go to load the portal login page.
I have never tampered with my DNS settings so I haven’t checked this scenario but it would explain it. I will go and try to test it somewhere around like starbucks or sometyhing similar.
Maybe you didn’t get the notification because of a predefined DNS setting.
As long as you don’t get the notification and use this to fill out the portal page it’s normal that you don’t have internet access…
I run into this at hotels and public WiFi and have rounded the cause down to being connected to a VPN. ( Both my home VPN or paid Proton VPN.) My process is to momentarily disconnect from the VPN, accept the terms of the WiFi and reconnect to the VPN.
Not sure why I have to do this but the workaround is easy enough that I haven’t worked very heard at it.
A network internal DNS can do any kind of hijack to direct your packets to the gateway that offers the http page with the Terms checkbox → afterwards your wifi cards MAC will be recorded in a table of devices having accepted the terms and traffic is routed. This is also how randomizing the MAC will require you to accept it again, but also resetting your traffic limit if one applies. None of this is accessible in a VPN, neither the internal DNS nor the page to accept the terms if both are network internal.
Usually you can check the gateway IP given to you by dhcp if it offers the accept term page on its http port - then you can keep your custom DNS config.
On some networks not all domains are hijacked, but only the default connectivity checks / portal detection of Google, Apple, Huawei, Samsung, Chrome and Firefox to redirect to the accept-terms page. If you have a custom check (as /e/ does), no redirect for you → If you don’t know your way around you’re stranded.
If I’d setup hotspots, I would advertise an accept-terms domain on public DNS, pointing to a stable internal network address that any hotspot network can resolve. This makes less assumptions and as a fallback can always work. Would really like to hear from someone in-the-know why this isn’t more widespread.
This sounds like very much what I experienced, some wifi portals worked and some not, with this knowledge I think I’ll be able to make it work now everywhere. Thanks a lot.
for most users I think the custom/secure DNS is the reason for this to fail. DoT/DoH only became a thing in the last few years and I guess hotspots lag in offering a robust answer to this (like advertising on public dns). There’s a standard in the works to do all of this early during dhcp and let users keep their external dns: RFC 8910: Captive-Portal Identification in DHCP and Router Advertisements (RAs)
Opening a non default browser then is actually of help, as e.g. in firefox case will emit to detectportal.firefox.com that most hotspots DNS will point to their onboard url. But again given you use the internal DNS…
… now I really need to check how far that rfc8910 is implemented in Android. I’m pretty sure it’s there already and it’s up to public networks to also implement. Sorry I could talk networks all day.
Just reporting back that this year no issues, same phone but later version of e/OS/ obviously. I did not even have to do anything has the check changed in e/OS/?