Find the answer to your Linux question:
Results 1 to 6 of 6
Symptom: On hardware I can wifi in to a "straight" hotspot / AP (like my router or an open router with no portal), but I cannot capture an ip address ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Linux User Steven_G's Avatar
    Join Date
    Jun 2012
    Location
    Western US
    Posts
    313

    Resolve (X) DNS "walled garden" / captive portal fails


    Symptom: On hardware I can wifi in to a "straight" hotspot / AP (like my router or an open router with no portal), but I cannot capture an ip address on wireless connections with a captive portal.

    Research: Default UB12.04 had a ~similar issue. It would "grab" the captive portal wifi connection /ip address. But, then when you opened your browser the connection would fail (time out) because dnsmasq could not resolve the pinned dns redirect to the EULA page inside the portal.

    UB devs claim they have fixed it, but I still can't get default UB12.04 to work on a captive portal inside VMs where I've attached a USB wifi; although, once again, that setup will connect to my router just like running on hardware will. In this setup, just like on hardware I cannot even capture the IP address on a wifi connection with a captive portal; the connection just times out. (Note: In the VM running default UB12.04 the only nameserver in /etc/resolv.conf is the local host.)

    According to some of the bug reports I read the hang up with a captive portal was there being up to 3 DNS "hand-offs" from / to different IPs inside the "walled garden" (their phrase, not mine) of a captive portal.

    Running my custom UB12.04 remix on hardware and using the built in wifi card I can't grab an IP address from a captive portal at all. I've been chasing this for a while.

    I've shut dnsmasq out of local DNS resolution in /etc/NetworkManager/NetworkManager.conf by commenting out DNS=dnsmasq.

    The network framework I have built in my custom UB12.04 remix using DHCP, Bind9 and network-manager has now been set to remotely resolve DNS straight from my box by prepending OpenDNS servers and using google to search for an unresolvable dns request in /etc/dhcp/dhclient.conf.

    It also automagically configures resolv.conf to grab DNS from 192.168.1.1 if it is available with OpenDNS being prefered. I am still learning and to be honest I'm not sure what subsystem is auto generating this configuration.

    As I write this and dig in to my system I *think* I have figured out what is wrong, but not how to fix it.

    The automaigical configuration in /etc/resolv.conf to resolve DNS from the LAN IP address (192.168.1.1) is the default automagical setup, even for a wireless connection.

    So, in resolv.conf my DNS resolution is being automagically set to 192.168.1.1 even though my home router wifi connection on wlan0 is 192.168.1.6 and I have verified this configuration by right clicking the nmaplet icon in the taskbar and opening "connection information"; both primary and secondary DNS resolution are set to 192.168.1.1?

    So, which automagical part of the system do I need to finagle to tell my system to grab DNS resolution directly off of the currently connected wifi IP address if it is available and not to default the wifi card to 192.168.1.1 for DNS resolution?

    And can any of the networking gurus tell me if that would even fix the problem or if I'm off and lost again?

    Code:
    usrer@machine:~$ cat /etc/NetworkManager/NetworkManager.conf
    
    [main]
    plugins=ifupdown,keyfile
    #dns=dnsmasq
    
    
    no-auto-default=XX:XX:XX:XX:XX:XX,XX:XX:XX:XX:XX:XX,
    
    [ifupdown]
    managed=false
    
    user@machine:~$ cat /etc/dhcp/dhclient.conf
    # Configuration file for /sbin/dhclient, which is included in Debian's
    #	dhcp3-client package.
    #
    # This is a sample configuration file for dhclient. See dhclient.conf's
    #	man page for more information about the syntax of this file
    #	and a more comprehensive list of the parameters understood by
    #	dhclient.
    #
    # Normally, if the DHCP server provides reasonable information and does
    #	not leave anything out (like the domain name, for example), then
    #	few changes must be made to this file, if any.
    #
    
    option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
    
    send host-name "<hostname>";
    #send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
    #send dhcp-lease-time 3600;
    #supersede domain-name "fugue.com home.vix.com";
    
    prepend domain-name-servers 208.67.222.222, 208.67.220.220
    
    request subnet-mask, broadcast-address, time-offset, routers,
    	domain-name, domain-name-servers, domain-search, host-name,
    	netbios-name-servers, netbios-scope, interface-mtu,
    	rfc3442-classless-static-routes, ntp-servers,
    	dhcp6.domain-search, dhcp6.fqdn,
    	dhcp6.name-servers, dhcp6.sntp-servers;
    #require subnet-mask, domain-name-servers;
    #timeout 60;
    #retry 60;
    #reboot 10;
    #select-timeout 5;
    #initial-interval 2;
    #script "/etc/dhcp3/dhclient-script";
    #media "-link0 -link1 -link2", "link0 link1";
    #reject 192.33.137.209;
    
    #alias {
    #  interface "eth0";
    #  fixed-address 192.5.5.213;
    #  option subnet-mask 255.255.255.255;
    #}
    
    #lease {
    #  interface "eth0";
    #  fixed-address 192.33.137.200;
    #  medium "link0 link1";
    #  option host-name "andare.swiftmedia.com";
    #  option subnet-mask 255.255.255.0;
    #  option broadcast-address 192.33.137.255;
    #  option routers 192.33.137.250;
    #  option domain-name-servers 127.0.0.1;
    #  renew 2 2000/1/12 00:00:01;
    #  rebind 2 2000/1/12 00:00:01;
    #  expire 2 2000/1/12 00:00:01;
    #}
    
    user@machine:~$ 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 208.67.222.222
    nameserver 208.67.220.220
    nameserver 192.168.1.1
    search google.com
    
    user@machine:~$ ifconfig
    eth0      Link encap:Ethernet  HWaddr 14:fe:b5:a1:74:81  
              inet6 addr: fe80::16fe:b5ff:fea1:7481/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:4009946 errors:0 dropped:0 overruns:0 frame:0
              TX packets:2081231 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:5989171866 (5.9 GB)  TX bytes:141673892 (141.6 MB)
    
    lo        Link encap:Local Loopback  
              inet addr:127.0.0.1  Mask:255.0.0.0
              inet6 addr: ::1/128 Scope:Host
              UP LOOPBACK RUNNING  MTU:16436  Metric:1
              RX packets:57884 errors:0 dropped:0 overruns:0 frame:0
              TX packets:57884 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0 
              RX bytes:2898642 (2.8 MB)  TX bytes:2898642 (2.8 MB)
    
    wlan0     Link encap:Ethernet  HWaddr 8c:a9:82:57:34:e2  
              inet addr:192.168.1.6  Bcast:192.168.1.255  Mask:255.255.255.0
              inet6 addr: fe80::8ea9:82ff:fe57:34e2/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:61238 errors:0 dropped:0 overruns:0 frame:0
              TX packets:30390 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:85376540 (85.3 MB)  TX bytes:3934865 (3.9 MB)
    
    user@machine:~$ iwconfig
    vboxnet0  no wireless extensions.
    
    eth0      no wireless extensions.
    
    lo        no wireless extensions.
    
    wlan0     IEEE 802.11bgn  ESSID:"XXXXXXXXX"  
              Mode:Managed  Frequency:2.462 GHz  Access Point: XX:XX:XX:XX:XX:XX   
              Bit Rate=1 Mb/s   Tx-Power=14 dBm   
              Retry  long limit:7   RTS thr:off   Fragment thr:off
              Power Management:off
              Link Quality=70/70  Signal level=-18 dBm  
              Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
              Tx excessive retries:7462  Invalid misc:469   Missed beacon:0
    Attached Images Attached Images

  2. #2
    Linux User Steven_G's Avatar
    Join Date
    Jun 2012
    Location
    Western US
    Posts
    313
    Still digging.

    I noticed that as I have been chasing this for several day now that I had added OpenDNS's nameserver IPs to both DHCP configuration and network/interfaces. So I commented them out in both places. I was tinkering / experimenting after that and "gummed up" my network protocols. I had to run:

    Code:
    sudo dpkg-reconfigure bind9
    sudo dpkg-reconfigure resolvconf
    sudo reboot
    to clear things up.

    I still have dnsmasq commented out in NetworkManager.conf (I've read some gurus who say it's baaaad).

    So now when I cat /etc/resolv.conf I get:
    Code:
     nameserver 192.168.1.1
    even though /etc/resolvconf/resolv.conf.d/base, ditto/head, ditto/original are all empty.

    So, I'm *assuming*, resolvconf has to be pulling the router IP from bind for DNS resolution.

    If that is the case then why is bind still not telling the wifi card to use the wireless IP for DNS resolution instead of the LAN IP (as per above) and why can't bind negotiate a captive portal?

    The captive portal part of it was supposed to be a dnsmasq issue and supposedly commenting dnsmasq out of NetworkManager.conf is supposed to shut it down completely. But, I'm not 100% sure on that? I don't see any running processes that appear to be invoking dnsmasq. But, it can't be uninstalled (easily) because network-manager depends on it.

    I think there's more here than meets the eye. I think the devs fouled something up because lots of people can't get through a captive portal.

    Could it be a resolvconf issue?

    As I understand it (now) when I had the OpenDNS servers in /etc/network/interfaces that was supposed to tell whatever network interface I opened to use those nameservers for DNS resolution. So why was the wifi trying to use the LAN IP for DNS?

  3. #3
    Linux User Steven_G's Avatar
    Join Date
    Jun 2012
    Location
    Western US
    Posts
    313
    OK, networking is not my strong suite and I got off on a tangent while investigating. After lots of reading and experimenting I can confirm that my wireless card is pulling the DNS resolution address from my router and my router always assigns it as itself / 192.168.1.1.

    And in the process of figuring that out I am now back to 100% OOB Ubuntu 12.04.2 default network configuration and it still won't connect to a captive portal; there's one close enough to my apartment to use as a reliable test.

  4. #4
    Linux User Steven_G's Avatar
    Join Date
    Jun 2012
    Location
    Western US
    Posts
    313
    Nobody has any ideas on this? I've done a ton of research on it and it comes down to two issues:

    1) DNS resolution

    2) FireFox and Chrome on *nix (maybe on doze?) do not have the abilty to "see" the redirect to the captive portal.

    I DL'd and tested in VMs ~30 distros. Most of them could not resolve the DNS of the portal and esatblish a connection. On the ones that could FF could not see the redirect and I was stuck on an error page.

    I tried old and new distros, 2.6 and 3.2 kernels, .deb, .rpm and independent systems and none of them worked.

    This is stupid. There has to be a solution.

  5. #5
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,672
    Your problem is your router config. You need to setup your router's DNS setting to point to a real DNS server. This information is then passed on to all the DHCP clients.

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  6. #6
    Linux User Steven_G's Avatar
    Join Date
    Jun 2012
    Location
    Western US
    Posts
    313
    No, it doesn't have anything at all to do with my router.

    This does not happen when I am connecting at home.

    It does not happen on a public or private wifi with or without a password so long as it is not behind a captive portal.

    It is two issues:

    1) Default Ubuntu 12.04 cannot see the multiple DNS redirects inside the walled garden of a captive portal per this ubuntu dev mailing list discussion.

    A little google goes a long way. They've been chasing this for years.

    I am *hoping* that some unconvential (for Ubuntu) stuff that I have done with DNS resolution will fix this. I need to test it.

    2) Per this patch report: FireFox cannot see the captive portal's HTTP or DNS redirect requests. They've finally fixed that. But the patch won't be included until FF21 (about 6-8 weeks from now it will hit the UB repos).

    Once again a little google goes a long way. They've been chasing this one for years as well.

    But I knew none of that when I got in to this. I'm a getting less noobish by the day. I've been doing massive data dumps all over my poor little brain for several week now. (Like 36 hours at a time, ain't Monsters great?)

    UB devs claim they have resolved the DNS issue in other places around the web. I have done EXTENSIVE testing and that HAS NOT been the case for me.

    I need to go test my "solution" to the DNS issue.

    And I am looking in to grabbing the FF source code and maybe compiling the patch in myself early. Although that will involve increasing my skill level. But that is true for nearly everything I am doing now.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •