10

Machine:

Ubuntu 17.10 Kernel 4.14 (for battery on my XPS 9560)

Steps to Recreate:

  • connect to the network (RED_STB)
  • enter a user and password
  • when I hit enter it redirects me to another page (wifiinstant.netsecure.pe) which says that it can't be reached, leaving me unconnected.

What have I tried:

  • Manually adding DNS to IPv4 NM settings
  • Adding connectivity to NetworkManager.conf
  • Reconfiguring resolvconf (sudo dpkg-reconfigure resolvconf)

A couple of key points:

  • it works on windows
  • I can connect to other networks no problem

Hardware: 

$ lspci | grep Net
02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)

NetworkManager Config: 

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

[device]
wifi.scan-rand-mac-address=no

[connectvitiy]
url=http://nmcheck.gnome.org/check_network_status.txt

Any ideas?

Brandon Bertelsen
  • 2,460

3 Answers3

11

Sitting at Starbucks now, it looks like I've found a workaround for this. In my case the error shows the hostname in quotes:

Error resolving “secure.datavalet.io”: Name or service not known

Work Around

  1. In a Terminal, find out the IP address of secure.datavalet.io.

      ip route

    (Example output: default via 172.31.98.1)

  2. run sudo nano /etc/hosts to add the IP address and hostname (from error) as a new line in your systems hosts file.

    172.31.98.1 secure.datavalet.io

  3. Usually optional, but in some cases where you've previously connected, you may need to also run sudo nano /etc/resolv.conf and insert a line for the first nameserver with the IP address:

    nameserver 172.31.98.1

  4. Try to connect to WI-FI again (e.g., through Firefox, which has the functionality of requesting the Network login page).

Explanation

It seems the problem is the hotspot server name (aka WiFi router) cannot be found during normal DNS lookup. This is due to a common out-of-spec router configuration, and the fact systemd operates according to RFC specification.

There is a bug report: 1766969 that seems to identify this problem with WiFi hotspots common to hotel WiFi, coffee shops, and other public WiFi configurations that work on Windows or Apple but not systemd. Hopefully the solution will allow it to fallback to older functionality to fix this common use case. On the bug report at the top, you have the option share that this bug affects you too, and/or be notified when resolved.

fosslinux
  • 3,881
Stepan Naumov
  • 144
0

This problem and multiple solutions can be found at any of the below. They are all address the same systemd-resolved issue: Ubuntu bug #1766969 Starbucks specific duplicate bug systemd-resolved specific duplicate bug

The best description & solution is in #1766969 from @markdaku summarized below:

Description: The internal resolver of systemd specified via the symlink /etc/resolv.conf is using /run/systemd/resolve/stub-resolv.conf. This file does not properly search the local dns, only fqdn's will resolve. This is easily mitigated and does not require a whole bunch of enabling or disabling of things (such as editing /etc/hosts). Instead use the pre-existing resolv.conf that actually works.

Solution: Delete the bad stub symlink and replace it with one pointing to the correct file.

sudo rm /etc/resolv.conf; sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

[Update] ^I just tested the above on 6.8.0-48-generic #48-Ubuntu and it works.

For completeness here is the systemd-resolved impact and solution. I didn't find it to be nearly as helpful as the above answer:

[Impact]

  • Certain WiFi captive portals do not support EDNS0 queries, as per RFC.
  • Instead of responding with the captive portal IP address, they resond with >domain not found
  • This prevents the user from hitting the captive portal login page, able to >authenticate, and gain access to the internets.

[The Fix]

  • As per tcp dumps, the problem arrises from receiving NXDOMAIN when queried >with EDNS0
  • And receiving the right response without EDNS0
  • The solution was to downgrade transactions, and retry EDNS0 + NXDOMAIN >result without EDNS0 with a hope of getting the right answer.
chevydog
  • 51
-1

The only workaround that I could find was to boot into Windows, connect, then boot back into Linux. Less than ideal but functional.

Brandon Bertelsen
  • 2,460