|
From: Michael B. <mb...@fe...> - 2002-12-12 18:56:08
|
On 12 Dec 2002, Eric W. Biederman wrote:
> > The original code was cleaner but apparently took up more space. It's
> > fairly straightforward: the DHCP request packet includes an option 175
> > which is a binary option with the structure:
> > Bus type (1 byte) : 1=PCI, 2=ISA
> > Vendor id (2 bytes)
> > Device id (2 bytes)
> > This is enclosed within an Etherboot encapsulated options field (i.e. an
> > option 150) in order to avoid pollution of the DHCP option namespace.
> > This data must be present in the DHCP request. It could be included in
> > the DHCP discover as well with no ill effects.
> Thinking:
> <-DISCOVER
> ->OFFER
> <-REQUEST
> ->ACK
> > It must be in the DHCP
> > request because the contents of the DHCP acknowledge will be derived from
> > the DHCP request (since DHCP is a stateless protocol). Since the DHCP
> > acknowledge includes the TFTP filename, which is the part most likely to
> > depend upon the PCI IDs, it is mandatory for the PCI IDs to be included in
> > the DHCP request.
> If the logic for in the DHCP server is:
> if (client_I_can_handle) {
> filename "x";
> }
> else {
> ...
> }
> Then etherboot must also send the information during the DISCOVER.
Any filename information sent in the OFFER will, AFAICR, be ignored by
Etherboot. It would perhaps be cleaner if the DISCOVER packet included
all the information; when I added PCI ID sending I followed the
pre-existing pattern of doing all the DHCP option stuff in the
REQUEST->ACK phase.
> > Feel free to tidy up the code but please don't change the data structures;
> > there are by now plenty of production systems that rely on it. You can
> > add other Etherboot-specific DHCP options within the encapsulated options
> > field, but if you change the structure of option 150 then you will be
> > breaking things.
> Here is my fundamental puzzlement. Why are we not using option 43 to
> transmit our data as well as receive it? It looks like that is
> exactly what Vendor Encapsulated Options is for, and using that field
> I do not see how we would conflict with anyone.
I've gone back and read over the discussion on the list when all this was
first added. Here's what I wrote at the time:
RFC1533_VENDOR_ETHERBOOT_ENCAP could be set equal to 43 (to use
vendor-encapsulated-options) or, alternatively, we could request a DHCP
option number from IANA. The latter may be preferable for two reasons:
1. It's quite conceivable that a vendor might wish to use Etherboot and
some of their own (unrelated to Etherboot) DHCP options. If the
Etherboot options go in vendor-encapsulated-options then we have yet
another option-space conflict, just in the vendor-encapsulated-options
space instead of the "raw" option space.
2. ISC DHCPD seems to have problems with extracting client-sent options
from vendor-encapsulated-options, although it will happily extract
options from any other encapsulated option field.
No-one disagreed; it got implemented. At the moment we are safe from
clashes unless someone else uses option 150, since option 150 can
encapsulate all other Etherboot options. This is the safest we can
possibly be without actually having an officially allocated number. If we
move to use vendor-encapsulated-options then we *increase* the risk of
clashes (and, as a side-effect, make it impossible to use some versions of
ISC DHCPD with Etherboot).
In addition to being safer, option 150 is in a significant amount of
production code (Mandrake 9.0, for example). Even if we changed it, we'd
probably have to still accept options returned via option 150.
Michael Brown
http://www.fensystems.co.uk
|
