[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