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

[Stephen Warren <swarren@wwwdotorg.org>]

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.