[RTEMS Project] #1406: Invariant dhcp transaction ID can confuse dhcp state machine.

[RTEMS trac]

#1406: Invariant dhcp transaction ID can confuse dhcp state machine.
------------------------+---------------------
 Reporter:  timcussins  |       Owner:  norume
     Type:  defect      |      Status:  new
 Priority:  normal      |   Milestone:  4.9.5
Component:  networking  |     Version:  4.9
 Severity:  normal      |  Resolution:
 Keywords:              |
------------------------+---------------------
Changes (by gedare):

 * milestone:  4.10 => 4.9.5


Old description:

> The dhcp code in rtems uses an unchanging transaction id (xid) in the
> dhcp discover and request packets.
>
> It is possible (and in fact has been observed) that dhcp servers may
> issue multiple OFFER packets in response to multiple REQUEST packets from
> the same device.
>
> The second OFFER packet could potentially be received while the dhcp
> state machine is waiting for an ACK packet - and this would cause the
> rtems dhcp process to fail needlessly.
>
> A solution to this is to use the transaction id field (described in the
> bootp/dhcp protocols) to match server dhcp replies with rtems dhcp
> requests.
>
> For details on the use of xid, see RFC 2131, Section 4.4.1
> (http://www.networksorcery.com/enp/rfc/rfc2131.txt)
>
> The patch creates a unique xid for each dhcp transaction: the
> DISCOVER/OFFER and REQUEST/ACK phases use different xid's, there is no
> confusion in the rtems state machine.

New description:

 The dhcp code in rtems uses an unchanging transaction id (xid) in the dhcp
 discover and request packets.
 It is possible (and in fact has been observed) that dhcp servers may issue
 multiple OFFER packets in response to multiple REQUEST packets from the
 same device.
 The second OFFER packet could potentially be received while the dhcp state
 machine is waiting for an ACK packet - and this would cause the rtems dhcp
 process to fail needlessly.
 A solution to this is to use the transaction id field (described in the
 bootp/dhcp protocols) to match server dhcp replies with rtems dhcp
 requests.
 For details on the use of xid, see RFC 2131, Section 4.4.1
 (http://www.networksorcery.com/enp/rfc/rfc2131.txt)
 The patch creates a unique xid for each dhcp transaction: the
 DISCOVER/OFFER and REQUEST/ACK phases use different xid's, there is no
 confusion in the rtems state machine.

--

--
Ticket URL: <http://devel.rtems.org/ticket/1406#comment:2>
RTEMS Project <http://www.rtems.org/>
RTEMS Project