dhclient -v wlan0 on eduroam suddenly fails: No DHCPOFFERS received.

cfr · 2016-09-10 17:34:42

Usually, I use netctl to connect to wireless networks, including eduroam.

However, today, I was unable to connect to eduroam despite sitting in the same chair at the same desk in the same building as yesterday, when it worked fine.

Killing off netctl and attempting manual configuration, I tried

ip link set dev wlan0 down
ip link set dev wlan0 up
iwlist wlan0 scan
iwconfig wlan0 essid "eduroam"
wpa_supplicant -B -c /etc/wpa_supplicant.conf -iwlan0

So far, so good. Everything seems OK.

Successfully initialized wpa_supplicant

However, attempting to lease an IP address goes badly.

dhclient -v wlan0

fails with output as follows.

Internet Systems Consortium DHCP Client 4.3.4
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit httXX://www.isc.org/software/dhcp/

Listening on LPF/wlan0/XX:XX:XX:XX:XX:XX
Sending on   LPF/wlan0/XX:XX:XX:XX:XX:XX
Sending on   Socket/fallback
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 17
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14
No DHCPOFFERS received.
Trying recorded lease 10.0.1.10
PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.

--- 10.0.1.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

No working leases in persistent database - sleeping.

10.0.1.10 fails because it is retrying something picked up on a different network.

The relevant entries from wpa_supplicant.conf are

network={
        ssid="eduroam"
        scan_ssid=1
        proto=WPA WPA2
        key_mgmt=WPA-EAP
        group=CCMP
        pairwise=CCMP
        eap=PEAP
        phase2="auth=MSCHAPV2"
        identity="username@uni.ac.uk"
        anonymous_identity="anonymous@university.ac.uk"
        password="XXX"
}

network={
        ssid="eduroam"
        scan_ssid=1
        proto=WPA WPA2
        key_mgmt=WPA-EAP
        group=CCMP
        pairwise=CCMP
        eap=TTLS
        phase2="auth=PAP"
        identity="username@uni.ac.uk"
        anonymous_identity="anonymous@university.ac.uk"
        password="XXX"
}

I am not entirely certain why I have two.

The eduroam netctl profile I have (which is not relevant to the connection attempt above but reflects the configuration which worked yesterday) is as follows.

Description='University Network: eduroam via PEAP/MSCHAPV2 (recommended)'
Interface=wlan0
Connection=wireless
Security=wpa-configsection
IP=dhcp
WPAConfigSection=(
    'ssid="eduroam"'
    'scan_ssid=1'
    'proto=WPA WPA2'
    'key_mgmt=WPA-EAP'
    'eap=PEAP'
    'group=CCMP'
    'pairwise=CCMP'
    'anonymous_identity="anonymous@university.ac.uk"'
    'identity="username@uni.ac.uk"'
    'password=hash:XXX'
    'phase2="auth=MSCHAPV2"'
)

I have seen the error from dhclient once before when I tried to connect on a different campus of the same institution. Usually, I connect there fine, but, in this case, all attempts failed with manual connection failing with the same message. Later the same day, on another part of campus, everything worked normally.

Could somebody suggest how I might diagnose the problem more precisely? I would particularly like to figure out, of course, what is going wrong and how I might fix it.

Last edited by cfr (2016-09-10 21:16:03)

cfr · 2016-09-13 00:35:35

So today, having made no changes whatsoever to anything --- or, rather, no non-temporary-debugging changes --- everything worked perfectly with my netctl profile, just as it did on Friday.

Since this is the second time this has happened, is there any way I can figure out what is going wrong? In particular, is there any way for me to be sure that there is something wrong on my side rather than the university's? If I could tell that it is not my fault, for example, next time it happens, then I could save a lot of wasted time attempting to troubleshoot a problem none of my making. On the other hand, if it is my fault, what am I missing in terms of diagnostics and troubleshooting?

Why would I not get any DHCP offers when everything seems to go smoothly up until that point? That is, the difficult eduroam authentication bit with all the inner and outer identity stuff all seems to go just fine. Only when it looks as if all is surely now plain sailing does a ruddy great iceberg appear in the form of an inability to get a lease. What could cause this?

Note that I have used some networks where there just weren't enough DHCP leases available. I'm pretty sure that isn't the case here. Our network is not great, but it isn't that bad. Moreover, even if that were the case at other times, it would not have applied on Saturday when I was sat in an all-but-deserted building. I should have had all of the leases usually available to two university departments at my disposal. The place should have been falling over itself to give me as many leases as I wanted.

Is it my fault and, if so, what am I doing wrong?

cfr · 2016-09-13 20:44:08

Yesterday it worked. Today it doesn't. There have been problems with eduroam but they are supposed to be fixed. However, neither I nor a Mac laptop user could connect today, even though other staff could connect fine with their various smart phones etc.

My logs were filled with messages of the following kind

Med 13 15:00:10 MyComputer kernel: IPv4: martian source 255.255.255.255 from 10.163.71.223, on dev wlan0
Med 13 15:00:10 MyComputer kernel: ll header: 00000000: ff ff ff ff ff ff dc ee 06 ff 5f eb 08 00        .........._...
Med 13 15:00:11 MyComputer kernel: IPv4: martian source 255.255.255.255 from 10.163.71.223, on dev wlan0
Med 13 15:00:11 MyComputer kernel: ll header: 00000000: ff ff ff ff ff ff dc ee 06 ff 5f eb 08 00        .........._...
Med 13 15:00:12 MyComputer kernel: IPv4: martian source 255.255.255.255 from 10.163.71.223, on dev wlan0
Med 13 15:00:12 MyComputer kernel: ll header: 00000000: ff ff ff ff ff ff dc ee 06 ff 5f eb 08 00        .........._...
Med 13 15:00:12 MyComputer kernel: IPv4: martian source 255.255.255.255 from 10.163.71.168, on dev wlan0
Med 13 15:00:12 MyComputer kernel: ll header: 00000000: ff ff ff ff ff ff 3c 15 c2 d7 ec 9a 08 00        ......<.......
Med 13 15:00:13 MyComputer kernel: IPv4: martian source 255.255.255.255 from 10.163.71.223, on dev wlan0
Med 13 15:00:13 MyComputer kernel: ll header: 00000000: ff ff ff ff ff ff dc ee 06 ff 5f eb 08 00        .........._...
Med 13 15:00:13 MyComputer kernel: IPv4: martian source 255.255.255.255 from 10.163.69.212, on dev wlan0
Med 13 15:00:13 MyComputer kernel: ll header: 00000000: ff ff ff ff ff ff e8 50 8b be 17 e1 08 00        .......P......
Med 13 15:00:14 MyComputer kernel: IPv4: martian source 255.255.255.255 from 10.163.71.223, on dev wlan0
Med 13 15:00:14 MyComputer kernel: ll header: 00000000: ff ff ff ff ff ff dc ee 06 ff 5f eb 08 00        .........._...
Med 13 15:00:15 MyComputer kernel: IPv4: martian source 255.255.255.255 from 10.163.71.223, on dev wlan0
Med 13 15:00:15 MyComputer kernel: ll header: 00000000: ff ff ff ff ff ff dc ee 06 ff 5f eb 08 00        .........._...
Med 13 15:00:16 MyComputer kernel: IPv4: martian source 255.255.255.255 from 10.163.71.223, on dev wlan0
Med 13 15:00:16 MyComputer kernel: ll header: 00000000: ff ff ff ff ff ff dc ee 06 ff 5f eb 08 00        .........._...
Med 13 15:00:17 MyComputer kernel: IPv4: martian source 255.255.255.255 from 10.163.70.26, on dev wlan0
Med 13 15:00:17 MyComputer kernel: ll header: 00000000: ff ff ff ff ff ff f4 5c 89 97 1a 95 08 00        .......\......
Med 13 15:00:17 MyComputer kernel: IPv4: martian source 255.255.255.255 from 10.163.71.223, on dev wlan0
Med 13 15:00:17 MyComputer kernel: ll header: 00000000: ff ff ff ff ff ff dc ee 06 ff 5f eb 08 00        .........._...
Med 13 15:00:17 MyComputer kernel: IPv4: martian source 255.255.255.255 from 10.163.69.42, on dev wlan0
Med 13 15:00:17 MyComputer kernel: ll header: 00000000: ff ff ff ff ff ff f4 5c 89 9e 2f 31 08 00        .......\../1..
Med 13 15:00:18 MyComputer kernel: IPv4: martian source 255.255.255.255 from 10.163.71.223, on dev wlan0
Med 13 15:00:18 MyComputer kernel: ll header: 00000000: ff ff ff ff ff ff dc ee 06 ff 5f eb 08 00        .........._...
Med 13 15:00:19 MyComputer kernel: IPv4: martian source 255.255.255.255 from 10.163.71.223, on dev wlan0

Again, I seem to be able to authenticate, but not get a lease. This time, however, I'm not getting a clear no-leases message.

Med 13 15:29:49 MyComputer wpa_actiond[3881]: Interface 'wlan0' connected to network 'eduroam'
Med 13 15:29:49 MyComputer dhclient[3889]: Corrupt lease file - possible data loss!
Med 13 15:29:49 MyComputer dhclient[3889]: Can't allocate interface wlease {
                                                 interface .
Med 13 15:29:49 MyComputer dhclient[3889]: 
Med 13 15:29:49 MyComputer dhclient[3889]: If you think you have received this message due to a bug rather
Med 13 15:29:49 MyComputer dhclient[3889]: than a configuration issue please read the section on submitting
Med 13 15:29:49 MyComputer dhclient[3889]: bugs on either our web page at www.isc.org or in the README file
Med 13 15:29:49 MyComputer dhclient[3889]: before submitting a bug.  These pages explain the proper
Med 13 15:29:49 MyComputer dhclient[3889]: process and the information we find helpful for debugging..
Med 13 15:29:49 MyComputer dhclient[3889]: 
Med 13 15:29:49 MyComputer dhclient[3889]: exiting.

I also found that I could not connect to the unsecured network. The IT guy insisted that to connect to eduroam 'the first time', you have to connect to the insecure network, log in and be transferred to eduroam. I am pretty sure I never did this ever. But I tried it anyway, I can connect OK, but I'm not transferred to the sign-in page when I open a browser and just get a "No internet connection".

Worse still, when I get home, I cannot connect here either. I'm still getting complaints about a corrupt lease. I would have thought that dhclient would have tried removing the current lease file, but apparently not.

I've now got back on my home network by removing

/var/lib/dhclient/dhclient.leases

and forcing creation of a new one. I have no idea if this was the correct thing to do or not.

1. Can anybody provide any insight into why this is happening?
2. How can I avoid it happening?
3. What is the best way to fix the problem when it does happen?
4. How I might possibly manage to connect to eduroam tomorrow?
5. What is all the 'martian source' stuff? I looked this up by googling and it seemed to indicate either a misconfigured network or a compromised network. Is that the university's fault or mine?

Last edited by cfr (2016-09-13 20:46:42)

Alad · 2016-09-14 11:08:45

I'm not sure what the particular issue is here, but I've had similar experiences with eduroam networks (across the channel). You can try getting more information by running wpa_supplicant in verbose mode:

wpa_supplicant -vvvvvv

You can also try if a different DHCP client makes a difference, e.g. dhcpcd, systemd-networkd or connman.

Last edited by Alad (2016-09-14 11:12:27)

cfr · 2016-09-14 15:19:40

Thanks Alad. I will try wpa_supplicant in verbose mode next time, although the logs suggested that authentication succeeded. (I think that's what wpa_supplicant does - please correct me if I'm wrong.)

Today it is working OK. But I'm still seeing complaints about martian sources and the weird 'll header's with the strange characters in the journal.

I actually switched to dhclient because dhcpcd had trouble with eduroam when my university upgraded the network. (Doesn't mean it might not work now, of course.) I also switched to netctl for this reason because wicd stopped being able to cope with the authentication process. However, it might definitely be worth trying an alternative to dhclient if I have trouble again. I guess that would mean going back to dhcpcd ... I know conman includes DHCP itself, but I'm a bit wary of it as it also tries to manage DNS and it isn't clear to me how to configure it for use with eduroam. (The wiki page doesn't say anything about this kind of authentication process, but only covers a simple example.) I don't think systemd-networkd would work for me, as I understand its capabilities because I need something which can adapt to different wireless networks automatically.

I am a little worried to discover that systemd-networkd.service and systemd-networkd.socket are listed by systemctl, albeit as dead/disabled/inactive. Should I disable these? There is also systemd-networkd-wait-online.service. I'm not sure if their presence indicates competition to manage wlan0/eth0. However, I've certainly never explicitly installed or enabled any of these service files.

● systemd-networkd.service - Network Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:systemd-networkd.service(8)
● systemd-networkd.socket - Network Service Netlink Socket
   Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.socket; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:systemd-networkd.service(8)
           man:rtnetlink(7)
   Listen: route 1361 (Netlink)
● systemd-networkd-wait-online.service - Wait for Network to be Configured
   Loaded: loaded (/usr/lib/systemd/system/systemd-networkd-wait-online.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:systemd-networkd-wait-online.service(8)

I don't like to disable them without being sure if I should because the man page mentions a role in transitioning from the real root to the initrd and back, which I obviously don't wish to mess up.

I am assuming it is not the management software (i.e. netctl) because, when I have problems, I have problems connecting manually as well. Since manual connection is the standard first-step, trying a different way of managing the connection automatically isn't really an option because I just don't get that far.

Do you know what the martian sources and weird headers are about? Googling suggested they could mean nothing good, so I'm slightly worried about the fact that they seem all over the place.

Last edited by cfr (2016-09-14 15:25:46)

Arch Linux

#1 2016-09-10 17:34:42

dhclient -v wlan0 on eduroam suddenly fails: No DHCPOFFERS received.

#2 2016-09-13 00:35:35

Re: dhclient -v wlan0 on eduroam suddenly fails: No DHCPOFFERS received.

#3 2016-09-13 20:44:08

Re: dhclient -v wlan0 on eduroam suddenly fails: No DHCPOFFERS received.

#4 2016-09-14 11:08:45

Re: dhclient -v wlan0 on eduroam suddenly fails: No DHCPOFFERS received.

#5 2016-09-14 15:19:40

Re: dhclient -v wlan0 on eduroam suddenly fails: No DHCPOFFERS received.

Board footer