[PATCH] libnetworking/rtems_dhcp.c: Fix invariant DHCP transaction IDs.

Aun-Ali Zaidi admin at kodeit.net
Mon Dec 28 18:23:21 UTC 2015


From: Tim Cussins <timcussins at 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




More information about the devel mailing list