[klibc] PATCH: ipconfig may discard useful packets

Άλκης Άλκης
Tue Oct 7 12:52:31 PDT 2008


Στις 07-10-2008, ημέρα Τρι, και ώρα 09:18 -0700, ο/η H. Peter Anvin
έγραψε:
>> Then it will prefer/accept the offer having the bigger gpxe.priority
>> (if any).
> The problem here is is that you're effectively trying to change the
> DHCP protocol to deal with your particular setup.  That isn't really a
> very practical option.

Peter, I've spent days reading the dhcp and bootp RFCs, and I'm pretty
sure that either you're wrong here, or that my English is not good
enough for me to understand what you're saying.

The DHCP protocol specifically allows for this kind of flexibility. I'll
quote some phrases from the RFCs.

If you're talking about the custom options (gpxe.priority or even
ipconfig.priority):
>From RFC1533:
> Option codes 128 to 254 (decimal) are reserved for site-specific
> options.
>From the "Table 5, Fields and options used by DHCP clients" in page 37
of RFC2131:
> Site specific:
> DHCPDISCOVER,DHCPINFORM => MAY
> DHCPREQUEST => MAY
> DHCPDECLINE => MUST NOT

A dhcp client is allowed to use custom options, so implementing such a
mechanism doesn't violate the protocol.
Besides, how are the sites supposed to use the custom options if the
dhcp client doesn't offer any way to use them?
gpxe and dhclient do offer such mechanisms, and *are* dhcp protocol
compliant.


If you're talking about the selection phase ("...it will wait for e.g. 1
second to collect dhcp offers"):
>From RFC2131:
> Note that the client may choose to collect several DHCPOFFER
> messages and select the "best" offer.  The client indicates its
> selection by identifying the offering server in the DHCPREQUEST
> message.  If the client receives no acceptable offers, the client
> may choose to try another DHCPDISCOVER message.  Therefore, the
> servers may not receive a specific DHCPREQUEST from which they can
> decide whether or not the client has accepted the offer.

And about the time the client waits:
> The client collects DHCPOFFER messages over a period of time, selects
> one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
> messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
> from the previously used server) and extracts the server address from
> the 'server identifier' option in the DHCPOFFER message.  The time
> over which the client collects messages and the mechanism used to
> select one DHCPOFFER are implementation dependent.

So it's perfectly valid for the dhcp client to wait and select whatever
the site administrator prefers.


> > As an alternative, I could implement the equivalents of the
> > "select-timeout" and "require" statements of dhclient.conf, which 
> > can also allow ipconfig to select one of many dhcp servers.
> 
> That has another problem, which is that in general you will not have 
> much sources of input to ipconfig. It is a more achievable solution, 
> though.
> 

I didn't understand the "you will not have much sources of input to
ipconfig" part. Do you mean that there aren't many sites that use more
than one dhcp server?
The DHCP protocol allows for many coexisting DHCP servers, so
implementing a mechanism in ipconfig for selecting one server out of
many, makes it more even more conformant to the protocol...


I really don't see the issue here. If you aren't interested in a patch
that does what I described, please tell me so, it'll be much simpler for
me to patch ipconfig a little just to make it work correctly in LTSP
labs with 2 dhcp servers.


Kind regards,
Alkis Georgopoulos



More information about the klibc mailing list