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

Andrew Falanga (afalanga) afalanga at micron.com
Mon Jan 22 19:34:30 UTC 2018

> -----Original Message-----
> From: dhcp-users [mailto:dhcp-users-bounces at lists.isc.org] On Behalf Of
> Simon Hobson
> Sent: Wednesday, January 17, 2018 2:35 PM
> To: Users of ISC DHCP <dhcp-users at lists.isc.org>
> Subject: [EXT] Re: Why is dhcpd not matching the MAC address as it should
> Andrew Falanga (afalanga) <afalanga at micron.com> 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)
> Note: the leading "1" is the hardware type, 1 indicating Ethernet.

Simon (and others),

Thank you for the insights.  I have at last figured out the recipe.  I had to change my pool declaration/definition to be

    pool {
        allow dynamic bootp clients;
        allow members of "controller";
        range dynamic-bootp;

I don't quite understand the reason why the server didn't figure out to allow them when the range had the "optional" modifier "dynamic-bootp" but with adding "allow dynamic bootp clients" to the pool definition, everything worked as it should.  

Thanks for the help and the insights.  Especially, thank you for the clarification that the binary-to-ascii function does return "both" 0's or leading 0's.  


More information about the dhcp-users mailing list