User manual

Etherboot User Manual

You could use a bootp daemon instead of a DHCP daemon. However DHCP is preferred as DHCP

provides more information to control the boot process. Also there is a bug in some old versions of bootpd

where unnecessarily large reply packets are sent, causing packet fragmentation at the UDP level, and

dropping of the packets by Etherboot. DHCPD can emulate bootpd if that’s what you really want.

4.3.1. REQUIRE_VCI_ETHERBOOT

You may need to Etherboot in an environment where you have to install your own DHCP server, and it

may interfere with the existing DHCP server. Etherboot has a feature designed to overcome this problem.

It consists of two parts:

The ﬁrst part is Etherboot contains code that when it sends out a DHCPDISCOVER request, a tag

containing a Vendor Class Identiﬁer of "Etherboot-x.y" is sent out, where x.y is the version number,

currently 5.2. The 5 and the 2 are printable digits, not binary values, i.e. byte values 53 and 50

respectively. This allows the server to identify Etherboot clients and ignore all others.

The second part is Etherboot can be conditionally compiled to require a Vendor Encapsulated Option

containing a VCI of "Etherboot", otherwise it will ignore the DHCPOFFER. The option is not compiled

in by default because it would cause Etherboot to not boot in plain setups. The server we want to respond

will include this tag in DHCPOFFERs and while other servers (e.g. Windows servers) may respond, they

will be ignored.

Vendor Encapsulated Option is supported in ISC DHCPD 2 or 3. (It’s not documented in DHCPD 2, but

it works.) Other DHCP servers may support VEO. (It’s a RFC2132 option.) In ISC DHCPD 3, follow the

documentation for declaring a VEO scope. In ISC DHCPD 2 the magic line required is:

option vendor-encapsulated-options 3c:09:45:74:68:65:72:62:6f:6f:74:ff;

Put this in the appropriate scope. Translation: Vendor Encapsulation Options (Option 43) encloses:

Vendor Class Identiﬁer (Option 60 = 0x3c), length 9, value "Etherboot"; End of Options (Option 255 =

0xff).

If you have a DHCP server already running for the subnet, you probably should specify that your

additional ISC DHCPD server is not authoritative for the the subnet, or it will veto (NAK) existing client

IP address allocations, upsetting the status quo. See the ISC DHCPD options documentation.

Here is a practical document ( http://www.geocrawler.com/archives/3/5299/2001/7/100/6129709/)

describing how it is done.

4.4. Setting up a tftp daemon

Now set up a tftp daemon. This means installing the tftp package and making sure that the tftp service is

active in

/etc/inetd.conf. If you want to be very careful you may wish to use the secure (-s) option

of tftpd, this chroots to the speciﬁed directory, but then your pathnames in

/etc/dhcpd.conf must be

relative to the new root directory.

If you are booting many clients you should be aware of the limitations of running tftpd from inetd.

Typically inetd has limits on how often a daemon can be spawned, to detect runaway daemons. If many

clients request the tftp service within a short period, inetd may shutdown that service. If you have a setup

where there are many clients, it may be better to use an improved replacement for inetd, such as xinetd.