Hello Michael, I was able to hit the bug again. It seems I have to go to another wifi network, then back to my home network to hit the bug. On the client-side, I get:
janv. 06 18:57:13 zoro NetworkManager[75721]: <info> [1578333433.9474] dhcp4 (wlp3s0): activation: beginning transaction (timeout in 45 seconds) janv. 06 18:57:13 zoro NetworkManager[75721]: <debug> [1578333433.9532] dhcp4 (wlp3s0): sent REQUEST to 255.255.255.255 janv. 06 18:57:13 zoro NetworkManager[75721]: <debug> [1578333433.9571] dhcp4 (wlp3s0): received NACK from 0.0.0.0 janv. 06 18:57:13 zoro NetworkManager[75721]: <info> [1578333433.9572] dhcp4 (wlp3s0): state changed unknown -> fail On the server-side, I am using dnsmasq. Logs say: Jan 06 18:51:39 eizo dnsmasq-dhcp[2841]: DHCPREQUEST(lan-trusted) 192.168.117.40 3e:55:59:b2:a3:b9 Jan 06 18:51:39 eizo dnsmasq-dhcp[2841]: DHCPNAK(lan-trusted) 192.168.117.40 3e:55:59:b2:a3:b9 address in use I am a bit puzzled why dnsmasq says that, but it didn't happen with older versions of Network Manager. If I capture the request and response, I get: 18:57:13.952425 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 317) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 3e:55:59:b2:a3:b9, length 289, xid 0xa9a8ed40, Flags [none] (0x0000) Client-Ethernet-Address 3e:55:59:b2:a3:b9 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Client-ID Option 61, length 7: ether 3e:55:59:b2:a3:b9 Parameter-Request Option 55, length 18: Subnet-Mask, Time-Zone, Domain-Name-Server, Hostname Domain-Name, MTU, BR, Classless-Static-Route Default-Gateway, Static-Route, YD, YS NTP, Server-ID, Option 119, Classless-Static-Route-Microsoft Option 252, RP MSZ Option 57, length 2: 576 Requested-IP Option 50, length 4: 192.168.117.40 Hostname Option 12, length 4: "zoro" END Option 255, length 0 18:57:13.952596 IP (tos 0xc0, ttl 64, id 26751, offset 0, flags [none], proto UDP (17), length 328) 192.168.117.1.67 > 255.255.255.255.68: [bad udp cksum 0x36ef -> 0x0984!] BOOTP/DHCP, Reply, length 300, xid 0xa9a8ed40, Flags [Broadcast] (0x8000) Client-Ethernet-Address 3e:55:59:b2:a3:b9 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: NACK Server-ID Option 54, length 4: 192.168.117.1 MSG Option 56, length 14: "address in use" END Option 255, length 0 PAD Option 0, length 0, occurs 34 But if I look at the lease file from dnsmasq, I see: 1578382414 e8:2a:ea:05:c0:df 192.168.117.40 zoro 01:e8:2a:ea:05:c0:df So, I suppose this is a because of randomizatio of the MAC address on wifi networks. I don't see anytrhing special in the NEWS file about this. Previously, the hardware MAC address was used to do the DHCP request. When using dhcp=dhclient, I am getting the same NAK, but then the ISC DHCP client is using DISCOVER and gets a new IP address. RFC says "If the client receives a DHCPNAK message, the client restarts the configuration process." So, I think the bug is more in the fact that the DHCP client doesn't restart configuration when receiving a NAK but just gives up. -- Localise input and output in subroutines. - The Elements of Programming Style (Kernighan & Plauger)
signature.asc
Description: PGP signature