lwIP - A Lightweight TCP/IP stack - Bugs: bug #29072, DHCPDISCOVER doesn't have ciaddr...
You are not allowed to post comments on this tracker with your current authentication level.
bug #29072: DHCPDISCOVER doesn't have ciaddr == 0
Submitter: | Bill Auerbach <billauerbach> | ||
Submitted: | Thu 04 Mar 2010 07:10:08 PM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | Faulty Behaviour | Status: | Fixed |
Privacy: | Public | Assigned to: | goldsimon |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | CVS Head |
Jump to the original submission
Mon 08 Mar 2010 09:23:11 PM UTC, comment #15: |
Bill Auerbach <billauerbach> |
Sat 06 Mar 2010 09:13:23 AM UTC, comment #14: Discussion about continuing LLA-connections should be continued in task #10241. |
Simon Goldschmidt <goldsimon> |
Fri 05 Mar 2010 07:06:52 PM UTC, comment #13: lol :-) I know I digressed into Link-Local Addressing (LLA) but this RFC for LLA does add constraints on DHCP. Since we support LLA (compliant or not) don't we now fall under RFC3927's DHCP provisions when LLA is enabled?
|
Bill Auerbach <billauerbach> |
Fri 05 Mar 2010 06:11:15 PM UTC, comment #12: I only wanted to point out that this is a different issue (worth of its own bug entry or task), not that I didn't want to implement it. And I certainly didn't want to hurt let alone seriously injure anybody! :-) |
Simon Goldschmidt <goldsimon> |
Fri 05 Mar 2010 05:36:01 PM UTC, comment #11: OK. It's the "host" side with the MUSTs.
|
Bill Auerbach <billauerbach> |
Fri 05 Mar 2010 04:50:34 PM UTC, comment #10: OK, but now you are talking about Link-Local Addressing, not DHCP. And as I see it, the RFC does not say "must not disturb" but "SHOULD" not, so we do respect the standard here.
|
Simon Goldschmidt <goldsimon> |
Fri 05 Mar 2010 04:32:31 PM UTC, comment #9: Mixing static is in fact valid using Link-Local Addressing (AutoIP). You will have a link local address and later DHCP provides an IP address. The RFC says you must not disturb connections on the link local address, you may use it thereafter and must use the DHCP provided address going forward. See RFC3927 - 1.9. |
Bill Auerbach <billauerbach> |
Fri 05 Mar 2010 04:20:12 PM UTC, comment #8: Well, until now I didn't think that anyone would mix setting a static IP address (netif_set_addr) with dhcp. And it looks like this combination leads to a wrong behaviour, so maybe dhcp_start should set the netif's address to zero.
|
Simon Goldschmidt <goldsimon> |
Fri 05 Mar 2010 03:43:10 PM UTC, comment #7: Ok, checked my code. I do dhcp_start and if I don't get an IP address in 5 seconds, I do netif_set_addr to a static fallback (but didn't do a dhcp_stop).
|
Bill Auerbach <billauerbach> |
Fri 05 Mar 2010 02:55:13 PM UTC, comment #6: Hm, when I set an IP-address before calling dhcp_start, I see that the IP-header source-address of the DHCP packets is that address, which I think is a bit odd, but still works.
|
Simon Goldschmidt <goldsimon> |
Fri 05 Mar 2010 01:58:15 PM UTC, comment #5:
|
Bill Auerbach <billauerbach> |
Fri 05 Mar 2010 01:37:42 PM UTC, comment #4: Should be fixed, thanks for reporting. |
Simon Goldschmidt <goldsimon> |
Fri 05 Mar 2010 01:14:42 PM UTC, comment #3: Bill, how did you get a ciaddr != 0 in a DHCPDISCOVER message? With the current code, ciaddr should only be set in states RENEWING or REBINDING, while DHCPDISCOVER is only sent in SELECTING.
|
Simon Goldschmidt <goldsimon> |
Fri 05 Mar 2010 01:07:42 PM UTC, comment #2: On second thought, I guess DHCPREQUEST should include ciaddr != 0 in BOUND/RENEW/REBIND, so the state check is still needed in addition to the message-type check. Sorry for the confusion.
|
Simon Goldschmidt <goldsimon> |
Fri 05 Mar 2010 12:54:50 PM UTC, comment #1: I'd fix this by passing the message-type to dhcp_create_request and basing the choice (whether to set ciaddr to zero or use netif->ip_addr) on the message-type instead of the current state.
|
Simon Goldschmidt <goldsimon> |
Thu 04 Mar 2010 07:10:08 PM UTC, original submission:
RFC2131 (4.4.1) calls for DHCPDISCOVER to have a ciaddr of 0.
|
Bill Auerbach <billauerbach> |
No files currently attached
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 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2010-03-05 | goldsimon | Status | None | Fixed | |
Open/Closed | Open | Closed | |||
2010-03-05 | goldsimon | Assigned to | None | goldsimon |
Powered by Savane 3.13-02a9.
Corresponding source code
I want to follow up on DHCP:
RFC2131 4.4.2 and 4.4.3 do mention MUST include your IP address in DHCPDISCOVER (if one is assigned) and that 'the client sends a DHCPINFORM message'. There is no MUST on this statement. If the user has to call dhcp_inform, we're leaving RFC-specific rules as a user's responsibility. Is this right?
And if we have an LLA assigned address and DHCP is continuing to operate then do we need to ensure that the subsequent DHCPDISCOVER's have the LLA? RFC 2131 doesn't stipulate a rule on the type of address if the device has one already but it makes sense to not send a routable address to it.