The rand() function doesn't produce a client specific random number. Its not clear to me how the bug is actually addressed.

On 28/12/15 19:23, Aun-Ali Zaidi wrote:
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.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to