[EXT] Re: Why is dhcpd not matching the MAC address as it should

[Andrew Falanga (afalanga)]

> > class "controller" {
> >    # tried matching based on two different styles I've seen on the net
> >    #match if substring(hardware, 1, 3) = 00:a0:45;
> >    match if (binary-to-ascii(16, 8, ":", substring(hardware, 0, 4)) =
> > "1:00:a0:45");
> 
> This won't match, the string "1" (that you've used) will not match the string
> "01" (what binary-to-ascii will generate). Also you are comparing FIVE bytes
> from the MAC address to FOUR bytes in the string. What you should do is
> simply compare the binary values :
> match if substring(hardware, 0, 3) = 1:00:a0:45; or match if
> substring(hardware, 1, 3) = 00:a0:45; (as you've shown as an alternative
> above)

I've done some further debugging and added some logging to dhcpd.c and 
recompiled my dhcpd binary.  Why is there no class types associated with
my packet?  This is from the dhcpd binary output after my additional log_debug
statements :

allocate_lease ENTRY
 pool 0x209de50, prohibit_list (nil), permit_list 0x209e040
 permitted ENTRY
     packet 0x20aad70, permit_list 0x209e040
     checking permit_list 0x209e040
     permit_list type 6
     permit_class type, class count 0

To make this relevant, I'm using version 4.3.4 of dhcpd.  On line number 4784
of server/dhcp.c , is the function allocate_lease().  At the start of the for loop
are calls to permitted().  In permitted() is a case statement looking at the packet
type.  It matches the case for *permit_class* which is expected since the config
file defines 2 classes.  However, as the last line of the output shows, there are 0
classes associated with this packet.  Why would that be?  There are 2 classes
defined, why aren't they associated with the struct packet instance being evaluated
in this block of code?  I hope I'm not chasing down a rabbit hole but this does seem
to be the root issue.

Andy