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

[Glenn Satchell]

This is a simple binary match on the hardware address, starting at offset
1 and 3 bytes long. So it doesn't care what the hardware type is.

match if substring(hardware, 1, 3) = 00:a0:45;

You could also, equally correctly, match starting at offset 0 and 4 bytes
long:

match if substring(hardware, 0, 4) = 01:00:a0:45;

In the dhcp-eval man page it defines the hardware operator:

"The hardware operator returns a data string whose first element is the
type of network interface indicated in packet being considered, and whose
subsequent elements are client's link-layer address. If  there  is  no 
packet, or if the RFC2131 hlen field is invalid, then the result is null. 
Hardware types include ethernet (1), token-ring (6), and fddi (8). 
Hardware types are specified by the IETF, and details on how the type
numbers are defined can be found in RFC2131 (in the ISC DHCP distribution,
this is included in the doc/ subdirectory)."

Secondly, in the range declaration for bootp clients you need to use this
syntax:

range dynamic-bootp 1.2.3.4;

Your original class is probably matching, but in the allowed subnet there
are no dynamic bootp addresses on offer. In the dhcpd.conf man page it
says:

"The dynamic-bootp flag may be specified if addresses in the specified
range may be  dynamically  assigned  to BOOTP clients as well as DHCP
clients."

regards,
-glenn

On Fri, January 19, 2018 5:03 am, Andrew Falanga (afalanga) wrote:
>
>> > 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
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>