GNOME Bugzilla – Bug 767515
internal dhcp doesn't work with my router (but dhclient works)
Last modified: 2020-11-12 14:30:00 UTC
Created attachment 329586 [details] Successful dhclient connection Setting dhcp=internal and connecting to my cheap Comfast CF-WR150N access point does not work. It only sends DISCOVER, but never gets any OFFER back from the DHCP server. I'm sure the actual problem is shitty DHCP implementation, but other people[1] on Arch Linux are seeing the same issues. There's probably lots of bad DHCP deployed. I'm attaching three tcpdumps, one with dhclient and two showing unsuccessful internal, and one using another access point. 1: https://bugs.archlinux.org/task/49160?project=1&cat%5B0%5D=2&string=networkmanager
Created attachment 329587 [details] Unsuccessful internal
Created attachment 329588 [details] internal successful on another router (not really relevant)
The only interesting differences I see are: 1) dhclient sends its request as Unicast, while internal sends as Broadcast. You can figure out if this is the problem by running something like: <stop NetworkManager> sudo dhclient -1 -v -d -B and seeing if you get a successful lease from the router. If you do, the broadcast flag is probably not the issue. 2) internal client is sending a ClientIdentifier. Some DHCP servers don't necessarily like the client ID. You can see if this is the problem by doing something like: sudo dhclient -1 -v -d -B -I "ff:ba:d2:08:e7:00:02:00:00:ab:11:04:ff:21:2d:12:90:ec:a9" and see if you get a response. If you could tcpdump this one too, that would be great so we can see if the client ID is the same on the wire as we expect.
Created attachment 329619 [details] [review] Truncate client_id to 7 chars So that was it. I was able to nail it down to the client ID needing to be 7 bytes or smaller in order for the router to give me an IP. dhclient does that, the internal one creates a hugely long client_id. The supplied patch fixes the problem for me. Although I'd guess this is not really a workable patch just truncating the id to 7. I tried figuring out a nicer way, but I've used too much time on this today :D
Maybe the server only understands RFC 2132 ethernet client-ids, which are 1+6 bytes, and doesn't like the RFC 4361-style client-id sent by default by the internal client. Do any of these work without your patch and dhcp=internal: $ nmcli connection modify <conn> ipv4.dhcp-client-id 01:xx:xx:xx:xx:xx:xx (where xx is a MAC address) $ nmcli connection modify <conn> ipv4.dhcp-client-id test ?
I’m affected by this issue two, and I can confirm that the client-id is the culprit. Sending the 01:xx… with MAC address worked. Sending "test" did not. Is there a way to send nothing at all btw?
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).