[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Bill Auerbach
Subject: [lwip-devel] [bug #27049] DHCP IP address assignment with multiple lwIP devices fails
Date: Mon, 20 Jul 2009 21:51:15 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2009060215 Firefox/3.0.11

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:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]