Struggling with classes not work

Mark Mc Nicholas markmcn at section9.ie
Tue Jan 5 12:47:59 UTC 2021


Hi Thomas,
Firstly thank you for testing that is a great help to know it's working :)
and my expectation of seeing the log line is correct.
I've just tried match if substring (option vendor-class-identifier, 0, 9) =
"Mips_boot"; and no joy

I then tried match if not (substring (option vendor-class-identifier, 0, 9)
= "Mips_boot"); which if I'm correct means that all devices should go into
this class (Which is fine on a test network)
but still it didn't work, I also tried match if not (option
vendor-class-identifier = "Mips_boot"); with the same logic of all devices
should go here.
However neither presented the next server or created the log line.
Using wireshark I took a look at the BOOTP request and the
vendor-class-identifier length is listed as being 9 the entry in the lease
file doesn't show anything other than the Mips_boot statement
Cheers
Mark

On Tue, Jan 5, 2021 at 12:33 PM Thomas Markwalder <tmark at isc.org> wrote:

> Hi Mark:
>
> I suspect Simon's hunch is correct, the vendor identifier may actually
> be longer than "Mips_boot".  I just tried this configuration snippet and
> it works fine:
>
>
> class "Mips_boot" {
>      match if (option vendor-class-identifier = "Mips_boot");
>      next-server 192.168.20.10;
>      log (info,"Devboot");
> }
>
> subnet 178.16.1.0 netmask 255.255.255.0 {
>      pool {
>          range 178.16.1.100 178.16.1.125;
>      }
> }
>
> I get the log statement and the client gets next-server.   If there are
> additional bytes after "Mips_boot" which you do not care about you can
> use substr:
>
> match if substring (option vendor-class-identifier, 0, 9) = "Mips_boot";
>
>
>
>
> On 1/5/21 7:22 AM, Simon Hobson wrote:
> > Mark Mc Nicholas <markmcn at section9.ie> wrote:
> >> Hey Simon,
> >> Thanks for the suggestion,
> >> I've just tried a very quick check changing the match statement to "
> match if vendor-class-identifier = "Mips_boot";"
> >> however from a very quick glance the result looked the same as the
> device didn't boot and I saw no log lines "Devboot" on the console.
> > One other thing to check is EXACTLY what the value is that you are
> testing for - in particular, look at a hex dump of the packet (or a decoded
> version of it). I've been caught out with things like trailing nulls, so
> it's 6 bytes of "value"0x00 not five bytes of "value" and the matching in
> dhcpd is very precise on this - they don't match.
> >
> > Simon
> >
> >
> > _______________________________________________
> > ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >
> > dhcp-users mailing list
> > dhcp-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/dhcp-users
>
> _______________________________________________
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>


-- 
Begin at the beginning,and go on till you come to the end: then stop.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20210105/dacdebab/attachment.htm>


More information about the dhcp-users mailing list