can't get option 82 data recognized by dhcpd

Denis Laventure Denis_Laventure at
Tue Feb 15 13:56:19 UTC 2011

Have you tried your match like this (removing leading 0 in hex match)?

match if option agent.circuit-id = 0:5;   # 00:05

match if option agent.remote-id = a:b5:1:1;   # 0a:b5:01:01

For debugging you could just add a log in your class definition:

log (info, "Matched CLASS-rule ...");


-----Message d'origine-----
De : at [ at] De la part de Ed Ravin
Envoyé : 14 février 2011 22:36
À : dhcp-users at
Objet : can't get option 82 data recognized by dhcpd

I am trying to get a lab network working with dhcpd-4.2.0-P2 and the option
82 data sent by an HP Procurve 2848 switch.

Here's what tcpdump says about the DHCP packet on the wire sent by
the client (and after being reformatted by the switch):

21:55:26.636756 IP (tos 0x0, ttl 127, id 57047, offset 0, flags [none],
proto UDP (17), length 338) > [udp sum ok]
BOOTP/DHCP, Request from 00:0d:56:df:1b:4f, length 310, hops 1, xid
0xaf116656, secs 1024, Flags [Broadcast] (0x8000)
	  Client-Ethernet-Address 00:0d:56:df:1b:4f
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Discover
	    NOAUTO Option 116, length 1: Y
	    Client-ID Option 61, length 7: ether 00:02:1f:28:1f:21
	    Requested-IP Option 50, length 4:
	    Hostname Option 12, length 7: "testbox"
	    Vendor-Class Option 60, length 8: "MSFT 5.0"
	    Parameter-Request Option 55, length 11: 
	      Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
	      Netbios-Name-Server, Netbios-Node, Netbios-Scope,
	      Static-Route, Classless-Static-Route-Microsoft, Vendor-Option
	    Vendor-Option Option 43, length 2: 220.0
	    Agent-Information Option 82, length 10: 
	      Circuit-ID SubOption 1, length 2: ^@^E
	      Unknown SubOption 2, length 4: 
		0x0000:  0ab5 0101
	    END Option 255, length 0

So agent.circuit-id is 00:05, and agent.remote-id is 0a:b5:01:01.  So far
so good.  But no matter what I do, dhcpd doesn't seem to recognize the
option 82 data.

Here's my dhcpd.conf, this is based on one of the examples at

but with diffent IP addresses and an extra class for testing:

stash-agent-options true;
log-facility local7;

shared-network "networkname" {
        subnet netmask {

                option broadcast-address;
                option routers;
                option subnet-mask;

                # test circuit-id
                class "id-" {
                        match if option agent.circuit-id = 00:05;
                pool {
                        allow members of "id-";
                # test remote-id
                class "id-" {
                        match if option agent.remote-id = 0a:b5:01:01;
                pool {
                        allow members of "id-";

                # sanity check
                class "has-option-82" {
                        match if exists agent.circuit-id or exists agent.remote-id;
                pool {
                        allow members of "has-option-82";

Note the comment "sanity check" - if there is any option 82 data
at all in the packet, that class should match, even if I typoed
the hex data that was supposed to match the circuit-id or remote-id.

I built dhcpd with -DDEBUG_CLASS_MATCHING to get a little extra output.
Here are the results when the client sends the packet shown above:

   checking against class id-
   checking against class id-
   checking against class has-option-82...
   DHCPDISCOVER from 00:0d:56:df:1b:4f via eth2.1: network networkname: no free leases

So what could be going on?  It looks like dhcpd thinks the packet doesn't
have any option 82 data in it.

At one point I had the IP assigned by dhcpd to this test
device, being a Windows box it looks like it is still asking for that
IP.  That should not make any difference, right?

Are there any more debugging flags I could try turning on?  I'm pretty
much out of ideas.


	-- Ed
dhcp-users mailing list
dhcp-users at

More information about the dhcp-users mailing list