Using hostname to assign devices to a class

Adam Raymond adam.m.r at gmail.com
Tue May 8 07:31:07 UTC 2018


Glenn,

  Thanks - it is usually the obvious things - I thought that those were
position values, not string lengths. I will give that try.

Adam

On Tue, May 8, 2018 at 5:24 PM, Glenn Satchell <glenn.satchell at uniq.com.au>
wrote:

> I think this might be it:
>
>   match if (substring (host-name,0,4)) = “estax”);
>
> The numbers in the substring() function are the offset and length. So
> you're comparing a 4 byte string with a 5 byte string - it'll never match!
>
> regards,
> -glenn
>
> On Tue, May 8, 2018 11:20 am, Adam Raymond wrote:
> > All,
> >
> >
> >
> >                 I have been having a long struggle to get the ISC DHCP
> > daemon to differentiate based on DHCP attributes so as to assign devices
> > to
> > different pools and trigger different scripts. I have 4 different models
> > at
> > the moment (and might expand this in the future) and the classes look
> like
> > this:
> >
> >
> >
> > class "GE112Pro" {
> >
> >         match if (option vendor-class-identifier) = "ADVA FSP
> > 150-GE112Pro"
> > ;
> >
> > }
> >
> >
> >
> > class "GE112ProH" {
> >
> >         match if (option vendor-class-identifier) = "ADVA FSP
> 150-GE112Pro
> > (H)";
> >
> > }
> >
> >
> >
> > class "XP116Pro" {
> >
> >         match if (option vendor-class-identifier) = "ADVA
> > FSP150CC-XG116PRO";
> >
> > }
> >
> >
> >
> > class "Overture" {
> >
> >         match if (substring (host-name,0,4)) = “estax†);
> >
> > }
> >
> >
> >
> > The subnet assignment looks like this:
> >
> >
> >
> > subnet 10.65.16.0 netmask 255.255.248.0 {
> >
> >         interface eth0;
> >
> >         option routers 10.65.23.254;
> >
> >         option subnet-mask 255.255.248.0;
> >
> >         option broadcast-address 10.65.23.255;
> >
> >
> >
> >         set location = "VIC";
> >
> >
> >
> >         pool {
> >
> >                 allow members of "GE112Pro";
> >
> >                 include "/etc/dhcp/GE112Pro.conf";
> >
> >                 range 10.65.23.236 10.65.23.240;
> >
> >         }
> >
> >
> >
> >         pool {
> >
> >                 allow members of "GE112ProH";
> >
> >                 include "/etc/dhcp/GE112ProH.conf";
> >
> >                 range 10.65.23.241 10.65.23.243;
> >
> >         }
> >
> >         pool {
> >
> >                 allow members of "XP116Pro";
> >
> >                 include "/etc/dhcp/XP116Pro.conf";
> >
> >                 range 10.65.23.244 10.65.23.245;
> >
> >         }
> >
> >         pool {
> >
> >                 allow members of "Overture";
> >
> >                 include "/etc/dhcp/on-commit.conf";
> >
> >                 range 10.65.23.246 10.65.23.249;
> >
> >         }
> >
> > }
> >
> >
> >
> > The problem I have is that the Overture device is being ignored by the
> > DHCP
> > daemon when it receives a discover packet. This is what a TCPDUMP of the
> > discover packet looks like:
> >
> >
> >
> > 01:46:27.024101 IP (tos 0x0, ttl 26, id 36818, offset 0, flags [none],
> > proto UDP (17), length 362)
> >
> >     10.65.23.253.bootps > man01.syd04.nsw.vocus.net.au.bootps: [udp sum
> > ok]
> > BOOTP/DHCP, Request from 00:0a:c6:51:1a:50 (oui Unknown), length 334, xid
> > 0x5a031d96, Flags [none] (0x0000)
> >
> >           Gateway-IP 10.65.23.253
> >
> >           Client-Ethernet-Address 00:0a:c6:51:1a:50 (oui Unknown)
> >
> >           Vendor-rfc1048 Extensions
> >
> >             Magic Cookie 0x63825363
> >
> >             DHCP-Message Option 53, length 1: Discover
> >
> >             PAD Option 0, length 0
> >
> >             MSZ Option 57, length 2: 1024
> >
> >             Parameter-Request Option 55, length 19:
> >
> >               Server-ID, Lease-Time, RN, RB
> >
> >               Subnet-Mask, Default-Gateway, Domain-Name-Server,
> > Domain-Name
> >
> >               BR, NTP, BF, Option 224
> >
> >               Option 225, Option 227, Option 228, Option 229
> >
> >               Option 230, Option 231, Option 232
> >
> >             PAD Option 0, length 0, occurs 3
> >
> >             Hostname Option 12, length 15: "estax-51-1a-50^@"
> > <<<<< What I am trying to filter on
> >
> >             PAD Option 0, length 0, occurs 3
> >
> >             Client-ID Option 61, length 15: "estax-51-1a-50"
> >
> >             PAD Option 0, length 0, occurs 3
> >
> >             T232 Option 232, length 18:
> > 12346,12848,12595,12593,12848,21553,13621,13104,13658
> >
> >             END Option 255, length 0
> >
> >             PAD Option 0, length 0
> >
> >
> >
> > Have I missed something obvious? I have tried a number of different
> > combinations of syntax here, most of which are excepted when I do the
> > restart of the daemon. I even have a work around that works: if you
> remove
> > the “Overture† class definition altogether and just create a generic
> > pool
> > at the end of the pool definitions, the DHCP daemon responds to the
> > requests, assigning a correct IP address and triggering the
> > “on-commit.conf† configuration.
> >
> >
> >
> > Would welcome any suggestions on what I have missed.
> >
> > Adam Raymond
> > _______________________________________________
> > dhcp-users mailing list
> > dhcp-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/dhcp-users
> >
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20180508/f149461b/attachment-0001.html>


More information about the dhcp-users mailing list