Re: [Etherboot-developers] [Q] How do we pass options to the DHCP server, are we failing?

[Michael B. <mb...@fe...>]

> 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.  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.

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.

Michael