[U-Boot] [PATCH] net: BOOTP retry timeout improvements

[Tom Rini]

On Mon, Aug 18, 2014 at 10:04:58AM -0600, Stephen Warren wrote:
> On 08/15/2014 03:39 PM, Thierry Reding wrote:
> >On Fri, Aug 15, 2014 at 10:02:40AM -0600, Stephen Warren wrote:
> ...
> >>Re-transmitting a DHCP request shouldn't prevent a response to the previous
> >>request from being processed - AFAIK each request is idempotent. Can you
> >>debug what is causing the 8s delay? Are earlier responses received and
> >>rejected for some reason, or is your DHCP server getting confused by the
> >>multiple requests and not responding, or ...?
> >
> >I haven't really tested this, but by looking at the code in net/bootp.c
> >(function BootpCheckPkt()) the U-Boot implementation will reject all
> >packets that don't match the BootpID (which is composed of the lower 4
> >bytes of the ethernet address plus the time in milliseconds when the
> >discover packet was sent, see BootpRequest()).
> >
> >So indeed earlier responses will be rejected, which would also explain
> >the 8 second delay since that's about the time it takes for the backoff
> >to reach the timeout that the server requires to reply before the next
> >retransmission.
> 
> Ah, that's a problem then, especially given that Thierry mentioned
> that (some) DHCP servers send out an ARP address and wait for any
> responses, to avoid address conflicts.
> 
> I suppose we have two options here:
> 
> a) Make each of U-Boot's DHCP requests identical, so that responses
> to an earlier request are accepted even if a later request has been
> sent. I don't know what the implications are here; perhaps some dumb
> DHCP server might give out different results for the different
> responses, so we actively don't want to accept the stale data?
> 
> b) Revert my patch. Perhaps think about tweaking the initial retry
> time-out later.
> 
> (b) seems simplest. Tom, it's f59be6e850b3 "net: BOOTP retry timeout
> improvements". It looks like nothing has touched the same files
> since it was applied, so it should be a simple revert.

I'm leaning this way as well for now and I see some "funny" behavior
sometimes in my setup, but not consistent (but I bet it's this same
thing) and I haven't had time to tcpdump it.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140818/fc44326e/attachment.pgp>