0

this problem seems to come in a lot of different flavors.

With my Ubuntu 18.04.3 LTS I can rarely use public Wifi because I cannot connect to the captive portal to login/"click connect".

In the KDE Networks tab I can connect to such a public wireless network. It shows as connected in the tab (Wifi symbol, no little question mark). However, I cannot resolve anything in the public Wifi network. If I type anything into chromium, chrome, or firefox I get DNS_PROBE_FINISHED_NO_INTERNET.

curl looks like this...

curl -v google.com
* Rebuilt URL to: google.com/
* Could not resolve host: google.com
* Closing connection 0
curl: (6) Could not resolve host: google.com

...ping like this.

ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
22 packets transmitted, 0 received, 100% packet loss, time 21325ms

Everything works without issues on an iPhone, an Android, and a Windows10.

Before you mark this as duplicate; I have found the solutions mentioned below. Unfortunately none of them worked for me. They appear in different threads but I think there are essentially 4:

ifconfig

wlp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.23.105.183  netmask 255.255.254.0  broadcast 10.23.105.255
        inet6 fe80::e275:f0ba:2953:9649  prefixlen 64  scopeid 0x20<link>
        ether b4:6d:83:cd:7e:9a  txqueuelen 1000  (Ethernet)
        RX packets 50246  bytes 14090564 (14.0 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 35844  bytes 5616976 (5.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

systemd-resolve --status

Global
         DNS Servers: 8.8.8.8
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

...

Link 3 (wlp3s0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 8.8.8.8
          DNS Domain: ~.
                      client.m3-hotspots.de

...

Update

I was on a German train again and as commented by waltinator I tried to curl and ping detectportal.firefox.com after adding 184.150.154.24 detectportal.firefox.com to /etc/hosts. ping didn't go through and curl returned 302 not found. I watched journalctl -f /usr/sbin/NetworkManager while trying to connect.

Dez 23 14:00:35 uranus NetworkManager[878]: <info>  [1577106035.2216] manager: NetworkManager state is now CONNECTED_LOCAL
Dez 23 14:00:35 uranus NetworkManager[878]: <info>  [1577106035.2285] manager: NetworkManager state is now CONNECTED_SITE
Dez 23 14:00:35 uranus NetworkManager[878]: <info>  [1577106035.2286] policy: set 'WIFIonICE' (wlp3s0) as default for IPv4 routing and DNS
Dez 23 14:00:35 uranus NetworkManager[878]: <info>  [1577106035.2308] device (wlp3s0): Activation: successful, device activated.
Dez 23 14:00:35 uranus NetworkManager[878]: <info>  [1577106035.2317] manager: NetworkManager state is now CONNECTED_GLOBAL

(no new log appeared while trying to connect)

However, the 302 response header looked like this:

Connection: close
Content-Length: 0
Date: Mon, 23 Dec 2019 13:08:28 GMT
Location: http://www.wifionice.de/de/?url=http%3A%2F%2Fdetectportal.firefox.com%2F
Server: squid
Via: 1.1 IMP-redirect (squid)
X-Cache: MISS from IMP-redirect
X-Cache-Lookup: MISS from IMP-redirect:3129

www.wifionice.de was the captive portal on that train. When opening detectportal.firefox.com in chromium I can see that the redirect to http://www.wifionice.de/de/?url=http%3A%2F%2Fdetectportal.firefox.com%2F is done, but the request to www.wifionice.de doesn't return. Curl returns this:

curl -v http://www.wifionice.de/de/?url=http%3A%2F%2Fdetectportal.firefox.com%2F                                         
* Could not resolve host: www.wifionice.de                                                                                              
* Closing connection 0                                                                                                                  
curl: (6) Could not resolve host: www.wifionice.de 
  • is the root of the problem that you are not pulling up the captive portal in the web browser or do you believe this is dns related. When using non-public networks (other than the one at one) do you have this problem? – stratus Dec 06 '19 at 13:33
  • To me it always happens in the ICE (german train) public net and in some hotels. To be honest I don't remember that this ever worked on my ubuntu 18.04 (using public wifi which requires to login w/ captive portal). – mRcSchwering Dec 06 '19 at 13:42
  • so I have started to pull up a browser on my own and surfing to either www.example.com or detectportal.firefox.com. I have found the captive portal detection to be wonky on most things (including my android phone). Try pulling up a non-http site – stratus Dec 06 '19 at 13:45
  • what do you mean by pulling up a non-http site? – mRcSchwering Dec 06 '19 at 13:48
  • use a web browser and try to browse to a website that does not use https. I realized there was a typoo in my response above. I have corrected that – stratus Dec 06 '19 at 13:51
  • ah, you mean http instead of https? Yes, doesn't work either. – mRcSchwering Dec 06 '19 at 13:56
  • This is crazy but I would try doing this: Edit your /etc/hosts and add this 184.150.154.24 detectportal.firefox.com and then try and browse there. Failing that, can you ping this ip? If for whatever reason dns queries are being blocked you may be able to fake your way around it – stratus Dec 06 '19 at 14:06
  • In a few days I'm back in the train, then I will try this :) – mRcSchwering Dec 06 '19 at 14:11
  • Watch the logs as you try to connect journalctl -f /usr/sbin/NetworkManager – waltinator Dec 06 '19 at 16:04
  • Was on a train yesterday and tried what you said. I updated the original question. – mRcSchwering Dec 24 '19 at 14:43

0 Answers0