Notice: We have migrated to GitLab launching 2024-05-01 see here:

#2877 closed defect (fixed)

DHCP client fails on complex networks

Reported by: Stavros Passas Owned by: joel.sherrill@…
Priority: normal Milestone: 5.1
Component: score Version: 5
Severity: normal Keywords: dhcp
Cc: Blocked By:


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.

Attachments (1)

fix-2877.patch (4.7 KB) - added by Stavros Passas on 01/20/17 at 09:33:28.

Download all attachments as: .zip

Change History (8)

comment:1 Changed on 01/20/17 at 09:25:37 by Sebastian Huber

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

comment:2 Changed on 01/20/17 at 09:27:16 by Stavros Passas

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

Changed on 01/20/17 at 09:33:28 by Stavros Passas

Attachment: fix-2877.patch added

comment:3 Changed on 01/20/17 at 09:33:55 by 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.

comment:4 Changed on 01/20/17 at 14:07:39 by Stavros Passas

Component: Generalcpukit
Owner: set to joel.sherrill@…

comment:5 Changed on 05/11/17 at 07:31:02 by Sebastian Huber


comment:6 Changed on 06/08/17 at 08:07:18 by Stavros Passas <stavros.passas@…>

Resolution: fixed
Status: newclosed

In [changeset:"258534718910c903451f1fe2e8fe1197c224c8e7/rtems" 2585347/rtems]:

network: Fix DHCP client protocol

Close #2877.

comment:7 Changed on 11/09/17 at 06:27:14 by Sebastian Huber


Milestone renamed

Note: See TracTickets for help on using tickets.