You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Briefly -- a DHCP Request receives a DHCP ACK from the server, but dhcpcd thinks that's a server claim for the address in question. Affected versions are 10.0.3, 9.4.1 and 8.1.4.
The setup is a basic dnsmasq-served ethernet LAN. That setup works fine when the same machine uses the NetworkManager machinery.
The dhcpcd logs are as follows, repeated ad infinitum:
Jan 25 03:23:02 host dhcpcd[14323]: eth0: dh:cp:se:rv:er:mc(dh:cp:se:rv:er:mc) claims 1.2.3.4
Jan 25 03:23:02 host dhcpcd[14323]: eth0: dh:cp:se:rv:er:mc(dh:cp:se:rv:er:mc) claims 1.2.3.4
Jan 25 03:23:02 host dhcpcd[14323]: eth0: 10 second defence failed for 1.2.3.4
Jan 25 03:23:02 host dhcpcd[14323]: eth0: deleting route to 1.0.0.0/8
Jan 25 03:23:02 host dhcpcd[14323]: eth0: deleting default route via 1.0.0.1
Jan 25 03:23:02 host dhcpcd[14323]: eth0: rebinding lease of 1.2.3.4
Jan 25 03:23:02 host dhcpcd[14323]: eth0: probing address 1.2.3.4/8
Jan 25 03:23:07 host dhcpcd[14323]: eth0: leased 1.2.3.4 for infinity
Jan 25 03:23:07 host dhcpcd[14323]: eth0: adding route to 1.0.0.0/8
Jan 25 03:23:07 host dhcpcd[14323]: eth0: adding default route via 1.0.0.1
Jan 25 03:23:08 host dhcpcd[14323]: eth0: dh:cp:se:rv:er:mc(dh:cp:se:rv:er:mc) claims 1.2.3.4
Jan 25 03:23:08 host dhcpcd[14323]: eth0: dh:cp:se:rv:er:mc(dh:cp:se:rv:er:mc) claims 1.2.3.4
Jan 25 03:23:08 host dhcpcd[14323]: eth0: 10 second defence failed for 1.2.3.4
Jan 25 03:23:08 host dhcpcd[14323]: eth0: deleting route to 1.0.0.0/8
Jan 25 03:23:08 host dhcpcd[14323]: eth0: deleting default route via 1.0.0.1
Jan 25 03:23:08 host dhcpcd[14323]: eth0: rebinding lease of 1.2.3.4
Jan 25 03:23:08 host dhcpcd[14323]: eth0: probing address 1.2.3.4/8
Jan 25 03:23:14 host dhcpcd[14323]: eth0: leased 1.2.3.4 for infinity
Jan 25 03:23:14 host dhcpcd[14323]: eth0: adding route to 1.0.0.0/8
Jan 25 03:23:14 host dhcpcd[14323]: eth0: adding default route via 1.0.0.1
Meanwhile, on the wire we see the following:
02:52:41.370524 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from cl:ie:nt:ma:ca:dr (oui Unknown), length 337
02:52:41.371083 IP server.bootps > 1.2.3.4.bootpc: BOOTP/DHCP, Reply, length 308
02:52:47.583527 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from cl:ie:nt:ma:ca:dr (oui Unknown), length 337
02:52:47.584122 IP server.bootps > 1.2.3.4.bootpc: BOOTP/DHCP, Reply, length 308
02:52:53.508164 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from cl:ie:nt:ma:ca:dr (oui Unknown), length 337
02:52:53.508768 IP server.bootps > 1.2.3.4.bootpc: BOOTP/DHCP, Reply, length 308
02:52:58.902490 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from cl:ie:nt:ma:ca:dr (oui Unknown), length 337
Good news is that master fixes the problem halfway. Halfway is because the client manages to get an address, just not what the server offers it in the initial reply.
Briefly -- a DHCP Request receives a DHCP ACK from the server, but
dhcpcd
thinks that's a server claim for the address in question. Affected versions are10.0.3
,9.4.1
and8.1.4
.The setup is a basic
dnsmasq
-served ethernet LAN. That setup works fine when the same machine uses the NetworkManager machinery.The
dhcpcd
logs are as follows, repeated ad infinitum:Meanwhile, on the wire we see the following:
..which, upon closer inspection (
tcpdump -v
) is:..i.e., a completely legitimate exchange.
IOW,
dhcpcd
is completely broken in this use case.NOTE: all IP addresses and hostnames were changed to protect the innocent.
dhcpcd
config is:The text was updated successfully, but these errors were encountered: