|
From: <ebi...@ln...> - 2002-12-12 18:31:07
|
Michael Brown <mb...@fe...> writes:
> > I am currently trying to get a grip on how we are passing options
> > to the DHCP server, and I think there are some problems, but I don't
> > quite get how we are encoding the options.
> > 1) We do not pass the NIC vendor and device id in the DHCP discover,
> > only in the DHCP request. If anything it should be the other way
> > around.
> > 2) I need pass the architecture etherboot is running on so I can
> > magically serve up an image that will boot. The plan is to extend
> > how we are passing the NIC id's, add another tag type, and pass
> > the ELF architecture type, we need it anyway for other reasons.
> > But the code is a little convoluted, and a first glance I don't get
> > how we are passing the NIC vendor and device ids.
> > Could someone give me a quick synopsis, of how we intend to be passing
> > the NIC vendor and device ids?
>
> 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.
Following the principle of be conservative in what you send, and be
liberal in what you accept, we should not plan of having the information
change during the REQUEST/ACK part of the configuration cycle, and instead
simply rely on that for confirmation.
> 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.
Eric
|
