After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 767515 - internal dhcp doesn't work with my router (but dhclient works)
internal dhcp doesn't work with my router (but dhclient works)
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: IP and DNS config
1.2.x
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2016-06-10 20:49 UTC by Odin Hørthe Omdal
Modified: 2020-11-12 14:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Successful dhclient connection (1.73 KB, application/octet-stream)
2016-06-10 20:49 UTC, Odin Hørthe Omdal
  Details
Unsuccessful internal (3.45 KB, application/octet-stream)
2016-06-10 20:50 UTC, Odin Hørthe Omdal
  Details
internal successful on another router (not really relevant) (2.13 KB, application/octet-stream)
2016-06-10 20:51 UTC, Odin Hørthe Omdal
  Details
Truncate client_id to 7 chars (816 bytes, patch)
2016-06-11 16:57 UTC, Odin Hørthe Omdal
none Details | Review

Description Odin Hørthe Omdal 2016-06-10 20:49:29 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
Comment 1 Odin Hørthe Omdal 2016-06-10 20:50:13 UTC
Created attachment 329587 [details]
Unsuccessful internal
Comment 2 Odin Hørthe Omdal 2016-06-10 20:51:43 UTC
Created attachment 329588 [details]
internal successful on another router (not really relevant)
Comment 3 Dan Williams 2016-06-10 21:50:11 UTC
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.
Comment 4 Odin Hørthe Omdal 2016-06-11 16:57:49 UTC
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
Comment 5 Beniamino Galvani 2016-06-14 09:38:17 UTC
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

?
Comment 6 bruno.n.pagani 2018-04-04 12:17:40 UTC
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?
Comment 7 André Klapper 2020-11-12 14:30:00 UTC
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).