Michael Brown <mb...@fe...> writes:
> On 12 Dec 2002, Eric W. Biederman wrote:
> > Currently etherboot does not interpret any encapsulated options
> > (except in the case of FreeBSD).
>
> Not quite sure what you mean here. Etherboot will accept any of the old
> Etherboot-specific options inside an etherboot-encapsulated-options field
> (i.e. a dhcp option 150).
But all such options have been removed from the core of etherboot,
with I believe the removal of the image menu.
Options always interpreted:
RFC1533_PAD
RFC1533_END
RFC1533_EXTENSIONPATH /* STD tftp file name of more options */
Options that are never used in encapsulated options:
RFC1533_NETMASK /* Standard */
RFC1533_GATEWAY /* Standard */
RFC1533_VENDOR /* Vendor encapsulated options */
RFC2132_MSG_TYPE /* Standard */
RFC2132_SRV_ID /* Standard */
RFC1533_HOSTNAME /* Standard */
RFC1533_VENDOR_ETHERBOOT_ENCAP /* Only truly etherboot specific option */
Options only interpreted in encapsulated options:
RFC1533_VENDOR_MAGIC /* Only option really used.. */
RFC1533_VENDOR_HOWTO /* FreeBSD only */
RFC1533_VENDOR_KERNEL_ENV /* FreeBSD only */
The only place etherboot specific options show up is in the code of mknbi....
> Option 128 is marked as ENCAP_OPT hence if ALLOW_ONLY_ENCAPSULATED is
> defined then it is valid only within etherboot-encapsulated-options and
> hence acts as a magic signature for the etherboot-encapsulated-options
> field.
I missed that one, so yes we have something that works there.
> > With respect to transmitting options I am less certain on how that
> > should be handled. But my gut impression says vendor encapsulated
> > options is the way to go. But it has been suggested that dhcpv3
> > cannot parse those options. I will at least want to verify that
> > before I go any further.
>
> There is a sample DHCPD config file in
> contrib/initrd/dhcpd.conf.etherboot.include. If you can achieve what is
> in there using vendor-encapsulated-options then one of my two objections
> to using VEO will disappear.
Thanks, I will take a look.
Eric
|