Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: Using the "vendor-class-identifer" to trigger different
scripts (Adam Raymond)
2. Re: Using hostname to assign devices to a class (Glenn Satchell)
3. Re: Using hostname to assign devices to a class (Adam Raymond)
----------------------------------------------------------------------
Message: 1
Date: Tue, 8 May 2018 13:23:41 +1000
From: Adam Raymond <adam....@gmail.com>
To: dhcp-users@lists.isc.org
Subject: Re: Using the "vendor-class-identifer" to trigger different
scripts
Message-ID:
<cafdogr5mcozer7zuhpwzjqnio2r+t7nk9ryqd3k3wwcfhk3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Sorry all: I managed to get around this. If you get rid of the "include"
statement in the class statement it works.
Adam
On Tue, May 8, 2018 at 1:03 PM, Adam Raymond <adam....@gmail.com> wrote:
> Hi,
>
> I have spent some weeks trying to ISC DHCP daemon to differentiate
> between different devices based on the "vendor-class-identifier" or option
> 60. This is sent to the DHCP server by the device types that I am trying to
> configure (in this case a ADVA GE112Pro) and identifies the model of the
> GE112Pro that is making the request - we need to configure the box
> differently depending on the model. It looks like this from a TCPDUMP: I
> have managed to get this working by fittering MAC addresses, but the
> different models all use the same OUI (first half of the MAC address) so
> cannot be differentiated on this basis.
>
> 05:45:53.216955 IP (tos 0x0, ttl 26, id 36530, offset 0, flags [none],
> proto UDP (17), length 341)
> 10.65.23.253.bootps > man01.syd04.nsw.vocus.net.au.bootps: [udp sum
> ok] BOOTP/DHCP, Request from 00:80:ea:ba:60:61 (oui Unknown), length 313,
> xid 0x5521f6bf, Flags [none] (0x0000)
> Gateway-IP 10.65.23.253
> Client-Ethernet-Address 00:80:ea:ba:60:61 (oui Unknown)
> Vendor-rfc1048 Extensions
> Magic Cookie 0x63825363
> DHCP-Message Option 53, length 1: Discover
> Lease-Time Option 51, length 4: 43200
> Hostname Option 12, length 17: "FSP150-GE112Pro-H"
> Parameter-Request Option 55, length 6:
> Subnet-Mask, BR, Time-Zone, Default-Gateway
> Domain-Name, Hostname
> Vendor-Class Option 60, length 25: "ADVA FSP 150-GE112Pro (H)"
> Client-ID Option 61, length 7: ether 00:80:ea:ba:60:61
> END Option 255, length 0
>
> Note: I would happily use option 12 (host-name) as well to make the
> differentiation. I still haven't been able to do this.
>
> Aside: I have been taking my names for options from
> http://www.ipamworldwide.com/ipam/isc-dhcpv4-options.html.
>
> Most of what I have read on the internet seems to push towards using a
> class to do this, similar to:
> class "ras-clients" {
> match if substring (option dhcp-client-identifier, 1, 3) = "RAS";
> }
>
> But I am yet to get this to work. A bit more information might be
> necessary. I am trying to trigger scripts with this differentiation. The
> subnet config looks like this:
>
> subnet 172.17.132.0 netmask 255.255.255.0 {
> interface eth0;
> option routers 172.17.132.1;
> option subnet-mask 255.255.255.0;
> option broadcast-address 172.17.132.255;
> next-server 172.17.132.68;
> option dhcp-renewal-time 300;
> option dhcp-rebinding-time 30;
> filename "adva_boot";
> option boot-server "labvm800.rlab.nn.com.au";
>
> set location = "QLD";
> include "/etc/dhcp/on-commit.conf";
>
> pool {
> max-lease-time 3600;
> range 172.17.132.115 172.17.132.117;
> }
> }
>
> The - include "/etc/dhcp/on-commit.conf"; - points to a file that looks
> like this:
>
> on commit {
> set clip = binary-to-ascii(10, 8, ".", leased-address);
> set clhw = concat (
> suffix (concat ("0", binary-to-ascii (16, 8, "",
> substring(hardware,1,1))),2), ":",
> suffix (concat ("0", binary-to-ascii (16, 8, "",
> substring(hardware,2,1))),2), ":",
> suffix (concat ("0", binary-to-ascii (16, 8, "",
> substring(hardware,3,1))),2), ":",
> suffix (concat ("0", binary-to-ascii (16, 8, "",
> substring(hardware,4,1))),2), ":",
> suffix (concat ("0", binary-to-ascii (16, 8, "",
> substring(hardware,5,1))),2), ":",
> suffix (concat ("0", binary-to-ascii (16, 8, "",
> substring(hardware,6,1))),2)
> );
> if (substring (clhw,1,8) = "00:80:ea") {
> execute("/usr/local/sbin/scriptA", "commit", clip, clhw,
> location);
> } else {
> execute("/usr/local/sbin/scriptB", "commit", clip, clhw,
> location);
> }
> }
>
> This works but has the issue of being tied down to MAC address matching,
> which in the case is pointless as we don't know if the individual MAC
> address and need to be albe to automatically determine the model and the
> UID is the same for each model.
>
> I have tried the class options with this configuration:
>
> default-lease-time 600;
> max-lease-time 7200;
>
> option domain-name "vocus.net";
> option domain-name-servers 172.16.79.1, 172.16.79.254;
> option ntp-servers 172.16.79.6, 172.16.79.2;
>
> class "GE112Pro" {
> match if (option vendor-class-identifier) = "ADVA FSP
> 150-GE112Pro" ;
> include "/etc/dhcp/GE112Pro.conf";
> }
>
> class "GE112ProH" {
> match if (option vendor-class-identifier) = "ADVA FSP 150-GE112Pro
> (H)";
> include "/etc/dhcp/GE112ProH.conf";
> }
>
> subnet 172.17.132.0 netmask 255.255.255.0 {
> interface eth0;
> option routers 172.17.132.1;
> option subnet-mask 255.255.255.0;
> option broadcast-address 172.17.132.255;
> next-server 172.17.132.68;
> option dhcp-renewal-time 300;
> option dhcp-rebinding-time 30;
>
> pool {
> allow members of "GE112Pro";
> include "/etc/dhcp/GE112Pro.conf";
> range 172.17.132.116 172.17.132.116;
> }
>
> pool {
> allow members of "GE112ProH";
> include "/etc/dhcp/GE112ProH.conf";
> range 172.17.132.115 172.17.132.115;
> }
> }
>
> This is on a separate server from the previous setup which is used for
> testing. This seems to work in that it assigns an IP address from the
> correct pool, but it doesn't run the script in question (which just writes
> a line to a file).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20180508/1ef96734/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 8 May 2018 17:24:08 +1000
From: "Glenn Satchell" <glenn.satch...@uniq.com.au>
To: "Users of ISC DHCP" <dhcp-users@lists.isc.org>
Subject: Re: Using hostname to assign devices to a class
Message-ID:
<77eee514800271d61fa56a02743f1c81.squir...@mail.uniq.com.au>
Content-Type: text/plain;charset=iso-8859-1
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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
------------------------------
Message: 3
Date: Tue, 8 May 2018 17:31:07 +1000
From: Adam Raymond <adam....@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Using hostname to assign devices to a class
Message-ID:
<cafdogr7mpbjazqwnyobm6ecakdkqxzdnevcjodo9yfmcdmx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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.satch...@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@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/dhcp-users
> >
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@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.html>
------------------------------
Subject: Digest Footer
_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 115, Issue 5
******************************************
