DHCP Transaction ID

[Tim Cussins]

Hey all,

I've experienced a slight problem with a particular router that is
exposing a race condition in the dhcp state machine.

Consider that a router might take too long to respond to our first
DISCOVER message, and we send another DISCOVER. The router in question
generates an OFFER for both messages.

If the code issues a REQUEST based on the first offer, it then listens
for an ACK - at this point the second OFFER may be received instead, the
code chokes, and it's all downhill from there (bad thing).

The problem here is that the *same* transaction id is used for
both the DISCOVER/OFFER and REQUEST/ACK phases: bootpc_call
(correctly IMO) checks for a reponse that has the correct opcode
(BOOTREPLY), and for the correct transaction id. As the id never
changes (in our implementation), the second OFFER is erroneously
accepted as the reponse.

Two solutions:
(1) patch bootpc_call() such that it parses the options field for code
    53 (dhcp message type) and checks it.
(2) use a unique transaction id for each exchange.

I feel (2) is a better solution - option parsing should be performed
outwith bootpc_call(), especially when using a different transaction id
(xid) appropriately will alleviate the problem.

>From RFC2131 (http://www.networksorcery.com/enp/rfc/rfc2131.txt) Section
4.1 "Constructing and sending DHCP messages"

   The 'xid' field is used by the client to match incoming DHCP messages
   with pending requests.  A DHCP client MUST choose 'xid's in such a
   way as to minimize the chance of using an 'xid' identical to one used
   by another client. For example, a client may choose a different,
   random initial 'xid' each time the client is rebooted, and
   subsequently use sequential 'xid's until the next reboot.  Selecting
   a new 'xid' for each retransmission is an implementation decision.  A
   client may choose to reuse the same 'xid' or select a new 'xid' for
   each retransmitted message.

My proposed patch updates the xid field using rand() in both
dhcp_discover_req() and dhcp_request_req(). This means a new xid for
each exchange.

I thought I'd raise a PR and attach the patch, but given the amount
of discussion about dhcp recently, I thought I'd get some thoughts
on it first.

Cheers, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dhcp_unique_xid.patch
Type: application/octet-stream
Size: 1135 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20090421/243d7b98/attachment.obj>