| Summary: | Support for "secs" in DHCP client | ||
|---|---|---|---|
| Product: | Busybox | Reporter: | Nikos Mavrogianopoulos <nmav> |
| Component: | Networking | Assignee: | unassigned |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | busybox-cvs |
| Priority: | P5 | ||
| Version: | 1.15.x | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: | DHCP secs patch | ||
|
Description
Nikos Mavrogianopoulos
2009-11-23 12:13:00 UTC
Looks like you forgot to attach the patch. Created attachment 771 [details]
DHCP secs patch
Came around to review the patch. It looks correct. Do you really see a case when DHCP servers need "seconds since I started" field filled in? I imagine most of them wouldn't care... (In reply to comment #3) > Do you really see a case when DHCP servers need "seconds since I started" field > filled in? I imagine most of them wouldn't care... I was also surprised by it. But it seems a client of us supported it and insisted on its support mentioning that it is being used to detect failed DHCP servers. (and proceed with failover procedure) > "that it is being used to detect failed DHCP servers."
How? I cannot imagine how "seconds elapsed" field is useful for this.
RFC 2131 does not seem to require this field to be set.
But if it is set to nonzero, RFC says:
"To help
ensure that any BOOTP relay agents forward the DHCPREQUEST message
to the same set of DHCP servers that received the original
DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
value in the DHCP message header's 'secs' field and be sent to the
same IP broadcast address as the original DHCPDISCOVER message."
So it becomes even less clear what this field is meant to contain... So far leaving it at zero looks like simplest and smallest (in code size terms) course of action.
Can you reproduce your complete conversation with the person requesting this?
You can post it here and/or on the mailing list.
(In reply to comment #6) > So it becomes even less clear what this field is meant to contain... So far > leaving it at zero looks like simplest and smallest (in code size terms) course > of action. > > Can you reproduce your complete conversation with the person requesting this? > You can post it here and/or on the mailing list. > Unfortunately not, and this conversation was long time ago and only roughly remember it. I can see however a discussion there that says how they use it: http://www.lithodyne.net/docs/dhcp/dhcp-5.html > load balance max seconds > This statement allows you to configure a cutoff after which load balancing is > disabled. The cutoff is based on the number of seconds since the client sent > its first DHCPDISCOVER or DHCPREQUEST message, and only works with clients > that correctly implement the secs field - fortunately most clients do. As far as I understand this field is being used to detect timeouts and proceed accordingly. Need more information on this (see comments). If you have some new, info, please reopen. |