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.