lwIP - A Lightweight TCP/IP stack - Bugs: bug #27049, DHCP IP address assignment with...
You are not allowed to post comments on this tracker with your current authentication level.
bug #27049: DHCP IP address assignment with multiple lwIP devices fails
Submitter: | Bill Auerbach <billauerbach> | ||
Submitted: | Fri 17 Jul 2009 05:04:50 PM UTC | ||
Category: | UDP | Severity: | 3 - Normal |
Item Group: | Faulty Behaviour | Status: | Fixed |
Privacy: | Public | Assigned to: | stoklund |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | CVS Head |
Jump to the original submission
Mon 27 Jul 2009 03:13:00 PM UTC, comment #29: |
Kieran Mansley <kieranm> |
Mon 27 Jul 2009 02:47:30 PM UTC, comment #28: Patches were committed Thursday, but I think the messages to lwip-commits were blocked because it was my first commit to lwip. I should have notified you, my bad. |
Jakob Stoklund Olesen <stoklund> |
Mon 27 Jul 2009 02:04:45 PM UTC, comment #27: Please do so, and then close this when done so I can prepare the next release candidate |
Kieran Mansley <kieranm> |
Wed 22 Jul 2009 04:38:39 PM UTC, comment #26: I will commmit the patches iof there are no objections |
Jakob Stoklund Olesen <stoklund> |
Wed 22 Jul 2009 03:03:42 PM UTC, comment #25: Great! I'm happy with this. Something about it is better. Although the 5th device retries a discover and gets the retried offer, the router processes the earlier request and ACKs it. I don't recall seeing this earlier.
|
Bill Auerbach <billauerbach> |
Wed 22 Jul 2009 12:55:58 PM UTC, comment #24: The patch in msg #23 doesn't have:
|
Bill Auerbach <billauerbach> |
Wed 22 Jul 2009 09:16:00 AM UTC, comment #23: Patch attached. Unfortunately I am not currently set up to test it.
|
Jakob Stoklund Olesen <stoklund> |
Wed 22 Jul 2009 08:03:49 AM UTC, comment #22: Happy to go with Jakob's solution as I too was concerned that by increasing the timeouts a little we'd just postpone the problem to a larger number of devices.
|
Kieran Mansley <kieranm> |
Tue 21 Jul 2009 09:40:56 PM UTC, comment #21: I should say, I don't have a problem with increasing the dhcp retransmission timeouts. In fact, RFC2131 ยง4.1 requires a randomized, exponential backoff with an initial value suited to the network speed.
That produces timeouts of 2, 4, 8, 16, 32, 60, 60, ... seconds.
|
Jakob Stoklund Olesen <stoklund> |
Tue 21 Jul 2009 08:41:14 PM UTC, comment #20: The problem with increasing the timeout is that it doesn't solve your problem. It looks like your router can make about one offer per second. This caused problems with an initial timeout of one second. If you increase the timeout to 4 seconds, you will get into trouble when you have 5 devices or more; 10 seconds, 11 devices. And so on.
|
Jakob Stoklund Olesen <stoklund> |
Tue 21 Jul 2009 08:10:05 PM UTC, comment #19: 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.
|
Bill Auerbach <billauerbach> |
Tue 21 Jul 2009 07:40:19 PM UTC, comment #18: Bill, the last pcaps you attached look perfectly healthy to me. Why do you think the DHCP server is starting over? The XID you mention goes like this:
|
Jakob Stoklund Olesen <stoklund> |
Tue 21 Jul 2009 06:55:44 PM UTC, comment #17: The question is whether the server must start over (according to the RFC) or if it is allowed to process every packet as it comes in. If it starts over, reusing XIDs won't change anything. However, if it doesn't (e.g. embedded device that takes some time for answering), things get easier when reusing XIDs.
|
Simon Goldschmidt <goldsimon> |
Tue 21 Jul 2009 06:23:52 PM UTC, comment #16: If the router starts over on a retry then it doesn't matter what the ID is does it? I now have 5 devices powering up together and I have a question in the PCAP. Why are there 2 back-to-back DHCP Requests from the same MAC? (packets 59 & 65) Oh, maybe it timed out and is re-requesting instead of ACKing. Again this points to timeouts being too short. |
Bill Auerbach <billauerbach> |
Tue 21 Jul 2009 06:12:45 PM UTC, comment #15:
|
Simon Goldschmidt <goldsimon> |
Tue 21 Jul 2009 05:32:08 PM UTC, comment #14: I have verified that with my router, if a DHCP discovery is started, any DHCP processing from the same MAC address is aborted. Therefore, I think there is no point in processing old DHCP offers because the router treats the ACK as invalid. |
Bill Auerbach <billauerbach> |
Tue 21 Jul 2009 03:52:33 PM UTC, comment #13: No, sorry. It looks like the repeated request has canceled the open offer and there is no DHCP ACK. The retried requests's offer is ACKed. Maybe you'll disagree. PCAP attached. The ID of interest ends in 5a4c.
|
Bill Auerbach <billauerbach> |
Tue 21 Jul 2009 03:35:38 PM UTC, comment #12: There must be another dhcp_set_state because on the timed out and retried DHCP Request, the ID has been incremented. The DHCP Offer was .4mS before the repeated request and wasn't processed. A request after a time out must be setting the state? |
Bill Auerbach <billauerbach> |
Tue 21 Jul 2009 08:15:58 AM UTC, comment #11: I think the proper solution would be to reuse XID for retransmissions. This is perfectly OK according to RFC2131.
|
Jakob Stoklund Olesen <stoklund> |
Mon 20 Jul 2009 09:51:14 PM UTC, comment #10: Right now, the timeouts in DHCP_SELECTING state are:
|
Bill Auerbach <billauerbach> |
Mon 20 Jul 2009 08:05:29 AM UTC, comment #9: I agree that adjusting the timeouts seems the most sensible approach. The question is to what? comment #7 alludes to something about 4 per 60 seconds from the RFC. Is there anything more concrete in the RFC (or other implementations) that we could follow? |
Kieran Mansley <kieranm> |
Sat 18 Jul 2009 08:46:42 AM UTC, comment #8: Unfortunately, I don't know the DHCP RFC very well, but it seems like our timeouts are at least not taken from there.
|
Simon Goldschmidt <goldsimon> |
Fri 17 Jul 2009 07:35:36 PM UTC, comment #7: It's a Cisco (LinkSys) 24 port GigE router. It could be part of the problem but being an industry standard small networking device, I would expect it to be fairly common but I suspect used mostly for PCs. PCs never come up together. Embedded devices can (and do).
|
Bill Auerbach <billauerbach> |
Fri 17 Jul 2009 07:18:28 PM UTC, comment #6: All 4 of my units now come up consistently in under 3.5 seconds with the following change in dhcp_discover:
|
Bill Auerbach <billauerbach> |
Fri 17 Jul 2009 07:13:40 PM UTC, comment #5: Looking at the pcap it seems the DHCP server is wrong, not the client. Could it somehow be that it is somehow overloaded and cannot respond fast enough?
|
Simon Goldschmidt <goldsimon> |
Fri 17 Jul 2009 06:32:06 PM UTC, comment #4: No, the IDs are unique.
|
Bill Auerbach <billauerbach> |
Fri 17 Jul 2009 05:52:28 PM UTC, comment #3: Just to be clear: It didn't help the repeating IDs, or it didn't help the DHCP server confusion? |
Robert Sprowson <sprow> |
Fri 17 Jul 2009 05:41:47 PM UTC, comment #2: Yes, I did add this DHCP_GLOBAL_XID define after seeing the repeating IDs hoping that it was the solution. It didn't help. |
Bill Auerbach <billauerbach> |
Fri 17 Jul 2009 05:25:41 PM UTC, comment #1: Did you define something (a rand() like function) for DHCP_GLOBAL_XID, per my patch #6763?
|
Robert Sprowson <sprow> |
Fri 17 Jul 2009 05:04:50 PM UTC, original submission:
Powering up multiple (3+) lwIP-based devices at the same time appears more often than not to confuse DHCP on all of the devices. When this occurs, none of the devices complete DHCP and none receive an IP address. By using WireShark, I can see the devices come up about 10mS to 15mS apart. The DHCP exchanges are all present and appear OK, but they are intermingled which is why I suspect they are confusing each other.
|
Bill Auerbach <billauerbach> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 10 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2009-07-27 | kieranm | Status | Ready For Test | Fixed | |
2009-07-27 | stoklund | Open/Closed | Open | Closed | |
2009-07-23 | stoklund | Status | None | Ready For Test | |
Assigned to | None | stoklund | |||
Planned Release | 1.3.1 | ||||
2009-07-22 | stoklund | Attached File | - | Added dhcp-backoff.patch, #18454 | |
2009-07-22 | stoklund | Attached File | - | Added dhcp-reuse-xid.patch, #18453 | |
2009-07-21 | billauerbach | Attached File | - | Added dhcp_5_devices.pcap, #18447 | |
2009-07-21 | billauerbach | Attached File | - | Added dhcp_4_devices.pcap, #18446 | |
2009-07-17 | billauerbach | Attached File | - | Added dhcp_4_devices.pcap, #18430 |
Powered by Savane 3.13-d3ae.
Corresponding source code
Thanks