[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DHCP Transaction ID
- Date: Tue, 21 Apr 2009 10:48:15 +0100
- From: timcussins at eml.cc (Tim Cussins)
- Subject: DHCP Transaction ID
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.
(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.