#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:
Blocking:

Description

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 Jan 20, 2017 at 9:33:28 AM.

Download all attachments as: .zip

Change History (8)

comment:1 Changed on Jan 20, 2017 at 9:25:37 AM by Sebastian Huber

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

comment:2 Changed on Jan 20, 2017 at 9:27:16 AM by Stavros Passas

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

Changed on Jan 20, 2017 at 9:33:28 AM by Stavros Passas

Attachment: fix-2877.patch added

comment:3 Changed on Jan 20, 2017 at 9:33:55 AM 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 Jan 20, 2017 at 2:07:39 PM by Stavros Passas

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

comment:5 Changed on May 11, 2017 at 7:31:02 AM by Sebastian Huber

Milestone: 4.124.12.0

comment:6 Changed on Jun 8, 2017 at 8:07:18 AM by Stavros Passas <stavros.passas@…>

Resolution: fixed
Status: newclosed

In 2585347/rtems:

network: Fix DHCP client protocol

Close #2877.

comment:7 Changed on Nov 9, 2017 at 6:27:14 AM by Sebastian Huber

Milestone: 4.12.05.1

Milestone renamed

Note: See TracTickets for help on using tickets.