The default value of the Siaddr field has changed

The ISC guys have decided to change the default behaviour of the DHCP Siaddr field between release 3.0.2 and 3.0.3.

Note that this change was considered to harmful by the ubuntu development team (its not nice to break user configurations with a minor version upgrade), it was reverted in ubuntu, so the following can be ignored by ubuntu users.

Fortunately, there's a simple fix.

The fix:

In the dhcpd.conf file, you need to add a line like this:

   next-server    192.168.0.254;

That entry should go near the top, so that it applies to ALL terminals. Make sure you put your server IP address in that entry!

The reason for the breakage:

In the DHCP reply offered by the server, there's a field called siaddr. This field is supposed to contain the IP address of the boot server. In versions of ISC dhcpd prior to 3.0.3, this field always defaulted to the value of the IP address of the dhcp server. As of ISC dhcpd version 3.0.3, it is now being zero filled.

Here's the entry in the release notes that describe the change that was made:

- The siaddr field was being improperly set to the server-identifier when
  responding to DHCP messages.  RFC2131 clarified the siaddr field as
  meaning the 'next server in the bootstrap process', eg a tftp server.
  The siaddr field is now left zeroed unless next-server is configured.

I've submitted a bug report to ISC, explaining that I think the field shouldn't default to zeros. We'll see if they accept it as a bug, and fix it for the next version. If not, then at least we have the easy fix of adding the 'next-server' entry to dhcpd.conf.

Thanks to Anselm Martin Hoffmeister, for spending the time last weekend tracking down this issue.

Jim McQuillan - Sept 9, 2005

Another view

The definition in the RFC does not specify the behaviour of how the DHCP server fills this field. However assuming that the DHCP server is also the TFTP server because the field was not set in the config file might be misleading. By explicitly requiring this field to be filled with a ono-zero value in order to point to a next stage server will result in a more clearly defined behaviour.

In this regard I support the ISC view of requiring an explicit definition.

-- HugoVanDerKooij - 18 Dec 2005