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
