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

Sebastian Huber sebastian.huber at embedded-brains.de
Mon Jan 4 10:39:26 UTC 2016


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 <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.

-- 
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.huber at embedded-brains.de
PGP     : Public key available on request.

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



More information about the devel mailing list