dhcp fails to obtain an ip address

[jack206]

When I change ip from static to dhcp,sometimes it failed to get ip. There have two dhcp server in the network. Packet capture is the same when the ip address is obtained and when the IP address is not obtained Here is the Packet:

[jack206]

use udhcpc-v eth0 can get ip。

[mdmillerii]

Phosphor networkd configures systemd networkd which is the actual DHCP client. Currently yocto is at v254.4 https://github.com/systemd/systemd-stable/blob/2e7504449a51fb38db9cd2da391c6434f82def51/src/network/networkd-dhcp4.c

You can see there are several debug traces that can be configured by adding a conf file for the unit in the drop in directory.

[mdmillerii]

You can find the current version of systemd from the bitbake recipe and it's include (.inc) in https://github.com/openbmc/openbmc/tree/master/poky/meta/recipes-core/systemd

[jack206]

Phosphor networkd configures systemd networkd which is the actual DHCP client. Currently yocto is at v254.4 https://github.com/systemd/systemd-stable/blob/2e7504449a51fb38db9cd2da391c6434f82def51/src/network/networkd-dhcp4.c

You can see there are several debug traces that can be configured by adding a conf file for the unit in the drop in directory.

Which commit is involved in this part? I'd appreciate it if you could elaborate

[mdmillerii]

I'm not sure what commit you are referring to. I was referring to the concept that most unit settings can be overridden by a conf file. Search for systemd conf drop in will find several tutorials on the concept in addition to the general systemd help https://www.freedesktop.org/software/systemd/man/latest/systemd.syntax.html#

I expect if you turn on systemd networkd debug logging you can gain insight and further debug information.

[jack206]

I'm not sure what commit you are referring to. I was referring to the concept that most unit settings can be overridden by a conf file. Search for systemd conf drop in will find several tutorials on the concept in addition to the general systemd help https://www.freedesktop.org/software/systemd/man/latest/systemd.syntax.html#

I expect if you turn on systemd networkd debug logging you can gain insight and further debug information.

I donot find any config to resolve it.

[jack206]

I see https://github.com/systemd/systemd-stable/blob/1b5bbbf7b48b36f5c6b6fec75093eb0f3f87aac2/src/libsystemd-network/sd-dhcp-client.c#L1756，it will restart the dhcp client when receive an NACK, Does anyone know why？Can we add a retry？

[mdmillerii]

RFC2131 is quite explicit for both client and server behavior including when a server MUST remain silent and not reply with a DHCPNAK.

If the client receives a DHCPNAK message, the client restarts the configuration process.

If one server is sending a DHCPNAK to the other servers DHCPOFFER on the same segment their configuration is broken. It is a race who wins (but DHCPACK inherently involves a commit to stable storage while a DHCPNAK does not, so it is NOT a fair race).

Your original packet capture does not display the Server Identifier defined in rfc2132 and whose usage specified in rfc2131. However, a casual reading implies it will be processed by the systemd client. This may or may not affect the response of the second server.

That said, the max delay on NAK in systemd-networkd seems comparable to an outage, while the delay in udhcpc seems to be much more aggressive (not scalable). I'd guess both will retry until they select an offer from the server that responds with an DHCPACK before the DHCPNAK from the competing server. (According to the RFC, the client retries start at 8s with exponential backoff to 64s and a smooth +-1s dither, although this is not directly related to DHCPNAK, as noted in the 2016 commit).

The OpenBMC policy is to work issues with the upstream code, so if you come up with a proposal you will need to discuss with systemd.

I suggest fixing your servers.

[jack206]

RFC2131 is quite explicit for both client and server behavior including when a server MUST remain silent and not reply with a DHCPNAK.

If the client receives a DHCPNAK message, the client restarts the configuration process.

If one server is sending a DHCPNAK to the other servers DHCPOFFER on the same segment their configuration is broken. It is a race who wins (but DHCPACK inherently involves a commit to stable storage while a DHCPNAK does not, so it is NOT a fair race).

Your original packet capture does not display the Server Identifier defined in rfc2132 and whose usage specified in rfc2131. However, a casual reading implies it will be processed by the systemd client. This may or may not affect the response of the second server.

That said, the max delay on NAK in systemd-networkd seems comparable to an outage, while the delay in udhcpc seems to be much more aggressive (not scalable). I'd guess both will retry until they select an offer from the server that responds with an DHCPACK before the DHCPNAK from the competing server. (According to the RFC, the client retries start at 8s with exponential backoff to 64s and a smooth +-1s dither, although this is not directly related to DHCPNAK, as noted in the 2016 commit).

The OpenBMC policy is to work issues with the upstream code, so if you come up with a proposal you will need to discuss with systemd.

I suggest fixing your servers.

Yeah，I read the udhcpc source code, which handles multiple dhcp servers, so you can get the ip quickly.(https://git.busybox.net/busybox/tree/networking/udhcp/dhcpc.c?h=1_28_stable),however, after receiving NACK, c systemed-network directly restarts the client. This seems normal

[mdmillerii]

Oh I missed that I happened on old 0.60 source and didn't see https://git.busybox.net/busybox/commit/networking/udhcp/dhcpc.c?h=1_28_stable&id=e2318bbad786d6f9ebff704490246bfe52e588c0 which is a refactor from https://git.busybox.net/busybox/commit/networking/udhcp/dhcpc.c?id=e2318bbad786d6f9ebff704490246bfe52e588c0 so open an issue with systemd for a similar feature...

[jack206]

Oh I missed that I happened on old 0.60 source and didn't see https://git.busybox.net/busybox/commit/networking/udhcp/dhcpc.c?h=1_28_stable&id=e2318bbad786d6f9ebff704490246bfe52e588c0 which is a refactor from https://git.busybox.net/busybox/commit/networking/udhcp/dhcpc.c?id=e2318bbad786d6f9ebff704490246bfe52e588c0 so open an issue with systemd for a similar feature...

Can systemed-network also be imported according to this revision? I lost track while trying to reference the patch. Do you have any ideas?

[mdmillerii]

BusyBox and systemd are unrelated code bases. You can request consideration of feature parity but it's not discussed in the specification and arguably the server is the errant party explicitly in the specification. I already referenced the issue tracker but a proposed patch would likely get faster attention.