Precise can't connect to a network guarded by an authentication webserver whose address can only be looked up with one of the nameservers whose address is provided by DHCP

[Sergio Callegari]

Hi,

our academic wifi, is protected with authentication practiced with a web page. The wifi network looks to be open to anyone, but to operate it after having connected the wifi you need to open a web page. This will automatically redirect you to an authentication page and after you are authenticated you can work on the wifi.

The problem is that with precise you can never get to the authentication page, since its url cannot be resolved.

The thing used to work fine with previous ubuntus and works fine with Windows.

Thanks in advance for looking into it.

Sergio

Related bugs:
 * bug 1003842: Upgrading to Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers
 * bug 997076: NM "dns=dnsmasq" breaks resolution of private domain names

[Thomas Hood (jdthood)]

I presume that the Ubuntu client associates to the access point and acquires an IP address via DHCP. Please let us know if this is not the case.

When you observe the reported problem on the affected system, please open a terminal and supply the console output of the following commands:

    ls -l /run/resolvconf /run/resolvconf/interface
    echo "=== /etc/resolv.conf ===" ; cat /etc/resolv.conf
    for F in /run/resolvconf/interface/* ; do echo "=== $F ===" ; cat $F ; done
    ps -elf|grep dnsmasq

[Sergio Callegari (callegar)]

Hi,
unfortunately, I have read your message too late and I cannot perform the test. I can however provide some additional info.

Our dhcp server provides the addresses of 3 nameservers. The first server is internal to our network and is the only one that can resolv the name of the web server that offers the authentication window. It is also probably the slower. The other two servers are external and cannot resolve the name of the internal authentication server.

I have a feeling that when these 3 nameservers go into resolv.conf, the resolver library tries them in order. Hence, the internal server is queried first and provides the name. Conversely, when these nameservers go into the dnsmasq conf and names start getting resolved with dnsmasq, the order is not followed anymore and the first server to answer says that the name cannot be resolved.

[Thomas Hood (jdthood)]

Based on the information you have provided so far I think that dnsmasq is the most likely culprit so I will reassign this issue over there.

If you get your hands on an affected machine then please let us know so that we can continue the investigation.

[Sergio Callegari (callegar)]

Here is the required data:

ls -l /run/resolvconf /run/resolvconf/interface
/run/resolvconf:
total 4
-rw-r--r-- 1 root root 0 mag 5 16:31 enable-updates
drwxr-xr-x 2 root root 60 mag 7 12:27 interface
-rw-r--r-- 1 root root 204 mag 7 12:27 resolv.conf

/run/resolvconf/interface:
total 4
-rw-r--r-- 1 root root 85 mag 7 12:27 NetworkManager

cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search wifi.mars.arces.unibo.it

for F in /run/resolvconf/interface/* ; do echo "=== $F ===" ; cat $F ; done
=== /run/resolvconf/interface/NetworkManager ===
domain wifi.mars.arces.unibo.it
search wifi.mars.arces.unibo.it
nameserver 127.0.0.1

ps -elf|grep dnsmasq
4 S nobody 25839 1652 0 80 0 - 7267 poll_s 12:27 ? 00:00:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec

[Sergio Callegari (callegar)]

Let me add that the /var/run/nm-dns-dnsmasq.conf contains 3 servers set by nm on activation of the wireless interface and received via dhcp.

The first one is internal. The other ones are external.

[Scott Moser (smoser)]

I've seen a problem like this before when logging into captive portals.
I could be wrong here but I think this is what the problem is:
 * user logs in once to captive portal, everything works fine
    * that included dns redirect from the server to captive portal
    * login
    * subsequent stuff working fine
 * Then, the user suspends and attempts to re-connect.
  * They try to go to some web location in firefox (or browser) which does a dns lookup, which *would* be redirected to the captive portal login. However, this time, resolvconf/dnsmasq has the right result cached and serves it. So instead of going to the captive portal login, the user can't do anything.

There may be one other step involved in this, possibly due to a redirect, but I think the issue is caching by dnsmasq.

[Sergio Callegari (callegar)]

No, unfortunately, I do not think it is that.

If I start with my machine OFF, I switch it on and boot, then I already have the issue.

The machine connects to the wifi, but when I open the browser I cannot reach the authentication screen because the name of the authentication host cannot be resolved.

If I try to resolve it with 'host' or 'dig', it cannot be resolved.

If I copy the nameserver entries from the dnsmasq configuration to /etc/resolv.conf then everything is fine.

[Thomas Hood (jdthood)]

Is there some officially correct way of disabling the NM-driven dnsmasq? If so, what is it?

When dnsmasq is disabled as above, does this problem (#993794) go away?

[Stéphane Graber (stgraber)]

Yep, the official way of turning dnsmasq off in NM is simply to comment the entry in /etc/NetworkManager/NetworkManager.conf

That's covered in http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/ (linked from the 12.04 release notes)

[Thomas Hood (jdthood)]

Sergio: When dnsmasq is disabled (by commenting out the entry in /etc/NetworkManager/NetworkManager.conf) does the problem (#993794) go away?

[Thomas Hood (jdthood)]

This issue doesn't affect resolvconf directly, so someone please remove resolvconf from the Affects list.

The malfunction described here is probably caused by #1003842.