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.
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
