[lwip-devel] [bug #27049] DHCP IP address assignment with multiple lwIP devices fails

[Bill Auerbach]

Follow-up Comment #10, bug #27049 (project lwip):

Right now, the timeouts in DHCP_SELECTING state are:

2, 3, 4, 10, 10 ... seconds. The change I made makes it:

4, 5, 6, 10, 10 ... seconds.  The only effect that will be noticed is if the
first DHCP offer is missed.  It will be 2 seconds longer to make another
request.  If there is no DHCP server, it's a moot point because it never
exists the DHCP_SELECTING state (AFAICT).  If AUTOIP is used, it checks
retries, so it will be 2 seconds later before falling back.  But without this
change and AUTOIP reties set to 1, it might fall back when it could have
received an address.

This only solves a problem, from what I see, when multiple units come up
together and possibly only with some routers.

The effect may only be present for a timed fallback such as I implemented. 
Although you could argue I should give it more time, the converse argument is
I don't think 20+ seconds for 4 units to acquire IP addresses is reasonable
when single devices do it in a couple of seconds.

Note that this timeout algorithm is repeated in a couple of places, but this
is for the case of waiting for a DHCP request.

I found nothing in DHCP RFCs that call out an explicit time out.  You could
conclude that a router manufacturer has no spec to follow as well. 
Considering the speed of a router and it's priority to deliver packets
quickly, I would expect its DHCP task to be a lower priority task.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?27049>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/