Re: [ECOS] dhcp XID generation

[Hugo Tyson <hmt@redhat.com>]

Robin Farine <acnrf@dial.eunet.ch> writes:
> In a system with a single power supply but many independent boards
> running eCos and using the DHCP client, switching the system on sometimes
> results into some boards configured with the *same* parameters (IP
> address, ...).

...and all using the same application binary, so (int)res is the same,
right, I can see that would be a problem.

> The problem resides in the method used to generate the DHCP request's XID
> field. A solution that seems to work for us follows:
> 
> <Changelog>
> 2001-05-03  Robin Farine  <acnrf@dial.eunet.ch>
> 
> 	* src/lib/dhcp_prot.c (do_dhcp): Uses arc4random() instead of
> 	cyg_current_time() to generate the XID field to improve randomness.
> </Changelog>
> 
> <patch>
> Index: packages/net/tcpip/current/src/lib/dhcp_prot.c
> ===================================================================
> RCS file: /usr/cvs/eCos/packages/net/net/tcpip/current/src/lib/dhcp_prot.c,v
> retrieving revision 1.1.1.1
> retrieving revision 1.2
> diff -r1.1.1.1 -r1.2
> 397c397
> <         xid = (cyg_uint32)res + (cyg_uint32)(0xffffffff & cyg_current_time());
> ---
> >         xid = (cyg_uint32)res + (cyg_uint32)arc4random();
> </patch>

Is that really random enough?  (Yes, I know the question has no meaning to
a true mathematician).  Yeah, the clock is free-running fast, in general.

You could just pick up the ESA from ifr.ifr_hwaddr.sa_data at that point, I
believe, to salt the token further.  It was set in bring_half_up(), as well
as later on in the routine.

	- Huge