Bug 2182555

Can you please capture a packet trace on the client machine?

In the capture NM is sending DHCP DISCOVER requests and is not getting any reply, while in the dhcpd log above we can see that the server is replying. So, it seems that OFFER packets are lost somewhere... what is the network topology?

Maybe you could compare the packets between a dhcp=dhclient and a dhcp=internal run to see what the difference is.

I was able to work around this on the server side by setting "always-broadcast on;" in the dhcp server for the affected clients (including my Steam Deck which runs NM under the hood). I guess the difference in response is unicast vs broadcast with this setting off/on.

The topology is just a few unmanaged switches. It's effectively one network with no special routing with a couple of consumer wifi routers running in AP-only mode.

NM has a way to request a broadcast reply to servers and that is by setting the ID_NET_DHCP_BROADCAST=1 udev attribute on the device; but AFAIK that is only needed in special cases such as on s390x guests, and I don't understand why dhclient would behave differently. If you have time to debug this, it would be useful to see a packet capture with dhclient to compare the discover packet with the one from the internal client. Thanks!

I've compared the REQUEST messages and the only differences are:

 - the internal clients sets "Seconds elapsed" to 1, while dhclient sets it to 0. The former is more correct since some servers or relays ignore packets with 0, see https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/341

 - the internal client sends options client-id=MAC and maximum-message-size=576; dhclient doesn't send them.

 - dhclient sends duplicated elements in the parameter-request-list option, but apart from this the elements are the same.

 - dhclient adds 29 bytes of zero-padding at the end of the packet (for a total of 342 bytes vs 324 for the internal client).

Note that both set the broadcast flag to "unicast".

The differences above don't seem significant to me; however the REQUEST from dhclient gets a reply, while the one from the internal client is ignored.

This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16.

Fedora Linux 36 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.