DHCPD missing router option in DHCPACK

Tom Griffin t.griffin at sheffield.ac.uk
Thu Jul 17 11:31:29 UTC 2008


Hello,

We have observed behaviour which has changed between versions of dhcpd.

We were previously running V3.0rc1pl1 with no failover configured. We 
have since tried both 3.1.1 and 4.0.0 with failover configured and found 
it to generate incorrect DHCPACK packets which are missing the router 
option for seemingly fine DHCPREQUESTs. This has so far only been 
observed with some models of HP printers (Laserjet 2600/1022/6310, 
Photosmart C5180, Officejet 7780).

A packet capture shows that the printers skip the DISCOVER/OFFER stage 
and move straight to REQUEST, requesting a specific IP and various 
options (in this order);
6 - Domain Name Server
3 - Router
1 - Subnet Mask
15 - Domain Name
66 - TFTP Server Name
67 - Bootfile Name
13 - Boot File Size
12 - Host Name

The dhcpd then responds with a DHCPACK containing the following options 
(in this order);
53 - DHCP Message Type
54 - Server Identifier
51 - IP Address Lease Time
6 - Domain Name Server
1 - Subnet Mask
1 - Subnet Mask
15 - Domain Name

Other requested options are not returned since they are not configured 
on the dhcp server (TFTP related options). Notice that the Subnet Mask 
option is duplicated and the router option is missing. The router option 
is definitely configured and working for the majority of devices on that 
subnet.

Here is the configuration of one of the many affected subnets;

  subnet 143.167.16.0 netmask 255.255.252.0 {
    option routers 143.167.16.254;
    pool {
      failover peer "coreserv";
      range 143.167.17.184 143.167.17.220;
      range 143.167.18.1 143.167.18.254;
      range 143.167.19.100 143.167.19.190;
      deny members of "subnetopen";
      deny members of "subnetnone";
      deny members of "ras-clients";
      deny unknown clients;
    }
  }

And here an example configuration of a host experiencing the issue;

  host prt019239 { hardware ethernet 00:17:a4:31:87:34; fixed-address 
143.167.19.239; }

As a work-around we are using BOOTP with the affected devices as this 
returns the correct information.

Regards,
Tom Griffin
Data Network Administrator
The University of Sheffield



More information about the dhcp-users mailing list