DHCP client fails on complex networks

[Stavros Passas]

What happens is that on networks with more than one DHCP servers, or on networks that use multiple vlans it can happen that After a DHCP discover our client broadcasts, it receives multiple offers, which is perfectly fine based on the DHCP RFC.

However our implementation of a DHCP client, expects a linear execution flow:

1. Broadcast a DHCP discover;
2. Wait for a DHCP offer;
3. Transmit a DHCP request;
4. Wait for a DHCP ack;

However the network stack is not cleaned between the reception of a DHCP offer and a DHCP ack, so if multiple offers are received, just the first one will be processed during the "Receive DHCP offer" phase, and the next one will be received when we expect a "DHCP ack", which makes our implementation assume the DHCP handshake is invalid and fail. Thus we restart the network and retry the whole process from the beginning which will cause the same issue again.

This issue that is present from when I remember in RTEMS, definitely from 4.10 up to now.

[Sebastian Huber]

The DHCP client used by libbsd is probably not affected by this problem.

[Stavros Passas]

Correct, this affects just cpukit/libnetworking/rtems/rtems_dhcp.c

[Stavros Passas]

I attach a file with a proposed fix for this DHCP client. mainly what the fix does is extend bootp_call to be able to expect a specific message as response. If it receives any other message, it will just ignore it, and it will timeout as it is expected to do in the first place.

Then with the extended bootp_call, I extended the dhcp client implementation to strictly expect a dhcp offer after a discover message and a DHCP ack after a request message. This way, the DHCP protocol does not fail if there are multiple DHCP messages on the network and it will finish successfully a DHCP handshake even when multiple messages are received from our client.

[Stavros Passas <stavros.passas@…>]

In 2585347/rtems:

network: Fix DHCP client protocol

Close #2877.

[Sebastian Huber]

Milestone renamed