From: Tim Cussins <timcuss...@eml.cc>
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.
Excerpt from RFC 2131:
4.4.1 Initialization and allocation of network address
......
The client generates and records a random transaction identifier and
inserts that identifier into the 'xid' field. The client records its
own local time for later use in computing the lease expiration. The
client then broadcasts the DHCPDISCOVER on the local hardware
broadcast address to the 0xffffffff IP broadcast address and 'DHCP
server' UDP port.
If the 'xid' of an arriving DHCPOFFER message does not match the
'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message
must be silently discarded. Any arriving DHCPACK messages must be
silently discarded.
......
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.
As bootpc_call() checks the xid of the BOOTREPLY, using a new xid prevents
packets related to
the previous transaction (DISCOVER/OFFER) from being accepted by bootpc_call().
closes #1406.
---
cpukit/libnetworking/rtems/rtems_dhcp.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/cpukit/libnetworking/rtems/rtems_dhcp.c
b/cpukit/libnetworking/rtems/rtems_dhcp.c
index cb6966d..144de17 100644
--- a/cpukit/libnetworking/rtems/rtems_dhcp.c
+++ b/cpukit/libnetworking/rtems/rtems_dhcp.c
@@ -518,8 +518,7 @@ process_options (unsigned char *optbuf, int optbufSize)
*/
static int
dhcp_discover_req (struct dhcp_packet* call,
- struct sockaddr_dl *sdl,
- unsigned long *xid)
+ struct sockaddr_dl *sdl)
{
int len = 0;
@@ -532,8 +531,7 @@ dhcp_discover_req (struct dhcp_packet* call,
call->htype = 1; /* 10mb ethernet */
call->hlen = sdl->sdl_alen; /* Hardware address length */
call->hops = 0;
- (*xid)++;
- call->xid = htonl (*xid);
+ call->xid = htonl (ntohl(call->xid) + rand());
call->flags = htons (DHCP_BROADCAST);
memcpy (&call->chaddr, LLADDR (sdl), sdl->sdl_alen);
@@ -612,7 +610,7 @@ dhcp_request_req (struct dhcp_packet* call,
call->htype = 1; /* 10mb ethernet */
call->hlen = sdl->sdl_alen; /* Hardware address length */
call->hops = 0;
- call->xid = reply->xid;
+ call->xid = reply->xid = htonl (ntohl(call->xid) + rand());
if (broadcast)
call->flags = htons (DHCP_BROADCAST);
else
@@ -891,7 +889,6 @@ dhcp_init (int update_files)
{
struct dhcp_packet call;
struct dhcp_packet reply;
- static unsigned long xid = ~0xFF;
struct ifreq ireq;
struct ifnet *ifp;
struct socket *so;
@@ -959,7 +956,8 @@ dhcp_init (int update_files)
/*
* Build the DHCP Discover
*/
- dhcp_discover_req (&call, sdl, &xid);
+ call.xid = htons (rand());
+ dhcp_discover_req (&call, sdl);
/*
* Send the Discover.
--
2.1.4
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
