lwip-devel
[Top][All Lists]
Advanced

[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: Tue, 21 Jul 2009 20:10:09 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11

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

Yes, it is slow.  I meant to say that the 5 device capture was a test - its
the original DHCP with accepting responses to XID and XID-1.  This way the
behavior is as-if the ID is the same, but I could see which packets the DHCP
server was replying to.

You're right, it's slow.  Each device makes it even slow, as if it has a
queue and processes them in order a little at a time.

I have also been corrected on something.  We have a 24-port switch and the
router running DHCP is the cable modem.  This helps explain the slowness I
think.

IMO, retries indicate a problem.  The retries should be eliminated if they
reasonably can be.  The initial timeouts seem to have been chosen because they
were reasonable when the code was developed.  I have a case that shows they
should be longer.  If it can take an off-the-shelf router to 4-5 seconds to
reply, then a 3 second timeout is going to be too short.

I guess I'm done arguing for longer timeouts.  No one has countered why it's
a bad idea or what could possible break or be effected by doing so.

I see no harm in repeating the IDs being used as suggested, but IMO it's only
helping the problem, not solving the problem.

I can test 5 devices coming up on our slow router and am happy to test
anything want to see.

    _______________________________________________________

Reply to this item at:

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

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





reply via email to

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