I rebooted a server after updating it (just found my password, so it's been a few months since it's updated), and now it can't connect to the network. dhcpcd simply prints:
dhcpcd: version 6.3.2 starting dhcpcd: DUID 00:01:00:01:1b:60:9d:3f:00:16:3c:04:ae:45 dhcpcd: ens3: IAID 3c:04:ae:45 dhcpcd: ens3: soliciting an IPv6 router dhcpcd: ens3: soliciting a DHCP lease dhcpcd: ens3: offered [IP it's supposed to have] from [DHCP Server of some sort] dhcpcd: ens3: ignoring offer of [IP I've never seen before] from [Another DHCP server?] dhcpcd: ens3: NAK: from [The second DHCP server]
and the last 4 lines (soliciting a DHCP lease) repeat.
Note: This might have some typos: I'm copying it by hand.
This persists on the Live CD (that's where the above log is copied from, but similar output existed on the pre-reinstallation server as well).
Curiouser and curiouser: dhcpcd --noarp works. Although I'm pretty sure that using it is incorrect, and probably implies significant issues somewhere.
Last edited by tikiking1 (2014-07-22 05:02:46)
First step for you is to update the system and check if the bug is present in 6.4.2. The latest dhcpcd release fixes several bugs such as infinite polling https://bugs.archlinux.org/task/39512
Uhhhh... How do I update without a network connection? This is a server I don't have physical access to (I can connect to the VM via VNC, though), and the only Arch ISO I can put in is 2014.06.01. The issue exists on that ISO, at least. Should I just bring it up with the host instead?
Just download the st dhcpcd package and install it
pacman -U ...
There are plenty of mirrors https://wiki.archlinux.org/index.php/Mirrors
Also there are other ways to setup the network, e.g. systemd-networkd https://wiki.archlinux.org/index.php/Systemd-networkd
Okay, newest dhcpcd doesn't fix it. I'm just gonna toss noarp in dhcpcd.conf and write it down somewhere.
Although you've fixed the problem by using noarp the truly Archy way is to send a report upstream and work with them on fixing the bug. At the project page you can find mailing list address to report about this problem http://roy.marples.name/projects/dhcpcd/index
We can talk about it here also
So, this isn't a bug with dhcpcd as such - you have two DHCP servers on your network and this is what is happening
dhcpcd: Hello Network - what is my address?
SERVER A: You can have address 1
SERVER B: You can have address 2
dhcpcd: can I have address 1 please?
SERVER A: YES
dhcpcd: cool, I'll be a good boy and check no-one else is using it by ARP checking because the DHCP server may not be on the same subnet and cannot know this
SERVER B: NO
dhcpcd: Oh dear. Hello Network what is my address?
And it continues.
So by disabling ARP checking it works because Server A responds faster then Server B, although this probably isn't a guarantee (sometimes Server B could respond faster)
Now, according to the RFC, if any server sends a NAK the DHCP client should roll back to the discover phase.
Luckily dhcpcd does provide a workaround - you can blacklist Server B by its Server ID, which is its IP address.
You can do this in dhcpcd.conf
The real solution though is to remove the rogue DHCP server from the network.
Last edited by rsmarples (2014-07-23 09:23:26)