|
|
|
|
Hi,
I running a DHCP Server version V3.1.1 and I have the following
situation in which I expect that pick-first-value works in a certain way
and do not get it.
I have this information from DHCP for the device:
Client-identifier: ff:10:08:19:d9:00:03:00:01:bc:c8:10:08:19:d9
Hardware: 1:bc:c8:10:8:19:d9
To obtain this information I use the following logs:
log (info, concat ("Lease request from hardware ", binary-to-ascii(16,
8, ":", substring(hardware, 0, 7)), " in subnet xx"));
log (info, concat ("Lease request from identifier ", binary-to-ascii(16,
8, ":", option dhcp-client-identifier), " in subnet xx"));
log (info, concat ("Lease request from suffix identifier ",
binary-to-ascii(16, 8, ":", suffix(option dhcp-client-identifier, 7)), "
in subnet xx"));
And the results is:
Apr 27 06:27:01 dev dhcpd: Lease request from hardware
1:bc:c8:10:8:19:d9 in subnet xx
Apr 27 06:27:01 dev dhcpd: Lease request from identifier
ff:10:8:19:d9:0:3:0:1:bc:c8:10:8:19:d9 in subnet xx
Apr 27 06:27:01 dev dhcpd: Lease request from suffix identifier
1:bc:c8:10:8:19:d9 in subnet xx
I use these very simple instructions to create a class and subclass:
class "test" { match pick-first-value (option dhcp-client-identifier,
hardware, suffix(option dhcp-client-identifier, 7)); }
subclass "test" 1:bc:c8:10:08:19:d9 {}
So, here the problem, I expect that if Client-identifier does not match
try with the hardware data and then with suffix data, right, but this
does not happen.
I change the match for this pick-first-value (hardware, option
dhcp-client-identifier) and then the device it's classified under the
test class.
I change the match for this pick-first-value (option
dhcp-client-identifier, suffix(option dhcp-client-identifier, 7),
hardware) and then the device it's not classified.
I change the match for this pick-first-value (suffix(option
dhcp-client-identifier, 7), option dhcp-client-identifier, hardware) and
then the device it's classified under the test class.
So, apparently pick-first-value classifies only when the first data
matches the declared value in a subclass.
I'm missing something ? It is this the behavior expected ? I copy below
what the manual says regarding pick-first-value:
pick-first-value (data-expr1 [ ... exprn ] )
The pick-first-value function takes any number of data expressions as
its arguments. Each expression is evaluated, starting with the first in
the list, until an expression is found that does not evaluate to a null
value. That expression is returned, and none of the subsequent
expressions are evaluated. If all expressions evaluate to a null value,
the null value is returned.
P.S.: I have solved my problem with the last example of a match, but I
wonder if I'm doing something wrong with my analysis.
Greetings, Bernardo.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Hi Bernado
pick-first-value is working as specified. The thing to be matched against
is the first non-null value in the list. Therefore in your first case
where you have:
match pick-first-value (option dhcp-client-identifier, hardware,
suffix(option dhcp-client-identifier, 7));
the thing to be matched against is option dhcp-client-identifier.
If you want to match against any of the three you need to use match ... or
... or ..., for example:
match (option dhcp-client-identifier or hardware or suffix(option
dhcp-client-identifier, 7));
regards,
-glenn
On Wed, April 27, 2016 11:59 pm, Bernardo wrote:
> Hi,
>
> I running a DHCP Server version V3.1.1 and I have the following
> situation in which I expect that pick-first-value works in a certain way
> and do not get it.
>
> I have this information from DHCP for the device:
>
> Client-identifier: ff:10:08:19:d9:00:03:00:01:bc:c8:10:08:19:d9
> Hardware: 1:bc:c8:10:8:19:d9
>
> To obtain this information I use the following logs:
>
> log (info, concat ("Lease request from hardware ", binary-to-ascii(16,
> 8, ":", substring(hardware, 0, 7)), " in subnet xx"));
> log (info, concat ("Lease request from identifier ", binary-to-ascii(16,
> 8, ":", option dhcp-client-identifier), " in subnet xx"));
> log (info, concat ("Lease request from suffix identifier ",
> binary-to-ascii(16, 8, ":", suffix(option dhcp-client-identifier, 7)), "
> in subnet xx"));
>
> And the results is:
>
> Apr 27 06:27:01 dev dhcpd: Lease request from hardware
> 1:bc:c8:10:8:19:d9 in subnet xx
> Apr 27 06:27:01 dev dhcpd: Lease request from identifier
> ff:10:8:19:d9:0:3:0:1:bc:c8:10:8:19:d9 in subnet xx
> Apr 27 06:27:01 dev dhcpd: Lease request from suffix identifier
> 1:bc:c8:10:8:19:d9 in subnet xx
>
> I use these very simple instructions to create a class and subclass:
>
> class "test" { match pick-first-value (option dhcp-client-identifier,
> hardware, suffix(option dhcp-client-identifier, 7)); }
> subclass "test" 1:bc:c8:10:08:19:d9 {}
>
> So, here the problem, I expect that if Client-identifier does not match
> try with the hardware data and then with suffix data, right, but this
> does not happen.
>
> I change the match for this pick-first-value (hardware, option
> dhcp-client-identifier) and then the device it's classified under the
> test class.
> I change the match for this pick-first-value (option
> dhcp-client-identifier, suffix(option dhcp-client-identifier, 7),
> hardware) and then the device it's not classified.
> I change the match for this pick-first-value (suffix(option
> dhcp-client-identifier, 7), option dhcp-client-identifier, hardware) and
> then the device it's classified under the test class.
>
> So, apparently pick-first-value classifies only when the first data
> matches the declared value in a subclass.
>
> I'm missing something ? It is this the behavior expected ? I copy below
> what the manual says regarding pick-first-value:
>
> pick-first-value (data-expr1 [ ... exprn ] )
>
> The pick-first-value function takes any number of data expressions as
> its arguments. Each expression is evaluated, starting with the first in
> the list, until an expression is found that does not evaluate to a null
> value. That expression is returned, and none of the subsequent
> expressions are evaluated. If all expressions evaluate to a null value,
> the null value is returned.
>
> P.S.: I have solved my problem with the last example of a match, but I
> wonder if I'm doing something wrong with my analysis.
>
> Greetings, Bernardo.
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users>
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Hi Glenn, thanks for your answer.
I tried with your proposal and gives me error:
class "test" { match (option dhcp-client-identifier or hardware or
^
Configuration file errors encountered -- exiting
The "^" it's points to hardware. Remember that I use the version 3.1.1.
Anyway, even though English is not my native language, I understand that
pick-first-value would have to return the match as the manual says "Each
expression is evaluated, starting with the first in
the list, until an expression is found that does not evaluate to a null
value.".
Cheers, Bernardo.
------ Original Message ------
From: "Glenn Satchell" < [hidden email]>
To: "Users of ISC DHCP" < [hidden email]>
Sent: 27/04/2016 11:07:21
Subject: Re: Unexpected behavior with pick-first-value
>Hi Bernado
>
>pick-first-value is working as specified. The thing to be matched
>against
>is the first non-null value in the list. Therefore in your first case
>where you have:
>
>match pick-first-value (option dhcp-client-identifier, hardware,
>suffix(option dhcp-client-identifier, 7));
>
>the thing to be matched against is option dhcp-client-identifier.
>
>If you want to match against any of the three you need to use match ...
>or
>... or ..., for example:
>
>match (option dhcp-client-identifier or hardware or suffix(option
>dhcp-client-identifier, 7));
>
>regards,
>-glenn
>
>On Wed, April 27, 2016 11:59 pm, Bernardo wrote:
>> Hi,
>>
>> I running a DHCP Server version V3.1.1 and I have the following
>> situation in which I expect that pick-first-value works in a certain
>>way
>> and do not get it.
>>
>> I have this information from DHCP for the device:
>>
>> Client-identifier: ff:10:08:19:d9:00:03:00:01:bc:c8:10:08:19:d9
>> Hardware: 1:bc:c8:10:8:19:d9
>>
>> To obtain this information I use the following logs:
>>
>> log (info, concat ("Lease request from hardware ",
>>binary-to-ascii(16,
>> 8, ":", substring(hardware, 0, 7)), " in subnet xx"));
>> log (info, concat ("Lease request from identifier ",
>>binary-to-ascii(16,
>> 8, ":", option dhcp-client-identifier), " in subnet xx"));
>> log (info, concat ("Lease request from suffix identifier ",
>> binary-to-ascii(16, 8, ":", suffix(option dhcp-client-identifier,
>>7)), "
>> in subnet xx"));
>>
>> And the results is:
>>
>> Apr 27 06:27:01 dev dhcpd: Lease request from hardware
>> 1:bc:c8:10:8:19:d9 in subnet xx
>> Apr 27 06:27:01 dev dhcpd: Lease request from identifier
>> ff:10:8:19:d9:0:3:0:1:bc:c8:10:8:19:d9 in subnet xx
>> Apr 27 06:27:01 dev dhcpd: Lease request from suffix identifier
>> 1:bc:c8:10:8:19:d9 in subnet xx
>>
>> I use these very simple instructions to create a class and subclass:
>>
>> class "test" { match pick-first-value (option dhcp-client-identifier,
>> hardware, suffix(option dhcp-client-identifier, 7)); }
>> subclass "test" 1:bc:c8:10:08:19:d9 {}
>>
>> So, here the problem, I expect that if Client-identifier does not
>>match
>> try with the hardware data and then with suffix data, right, but this
>> does not happen.
>>
>> I change the match for this pick-first-value (hardware, option
>> dhcp-client-identifier) and then the device it's classified under the
>> test class.
>> I change the match for this pick-first-value (option
>> dhcp-client-identifier, suffix(option dhcp-client-identifier, 7),
>> hardware) and then the device it's not classified.
>> I change the match for this pick-first-value (suffix(option
>> dhcp-client-identifier, 7), option dhcp-client-identifier, hardware)
>>and
>> then the device it's classified under the test class.
>>
>> So, apparently pick-first-value classifies only when the first data
>> matches the declared value in a subclass.
>>
>> I'm missing something ? It is this the behavior expected ? I copy
>>below
>> what the manual says regarding pick-first-value:
>>
>> pick-first-value (data-expr1 [ ... exprn ] )
>>
>> The pick-first-value function takes any number of data expressions as
>> its arguments. Each expression is evaluated, starting with the first
>>in
>> the list, until an expression is found that does not evaluate to a
>>null
>> value. That expression is returned, and none of the subsequent
>> expressions are evaluated. If all expressions evaluate to a null
>>value,
>> the null value is returned.
>>
>> P.S.: I have solved my problem with the last example of a match, but
>>I
>> wonder if I'm doing something wrong with my analysis.
>>
>> Greetings, Bernardo.
>>
>> _______________________________________________
>> dhcp-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users>>
>
>
>_______________________________________________
>dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
ok, thinking more about it, that syntax won't work.
However, what's happenning in your case is that the option
dhcp-client-identifier is non-null so gets chosen but that string doesn't
match the sub-class string. What it doesn't do is match any of the three,
and thinking about it I can't see how you might do that without a gian
'if' statement.
It looks like you have read the dhcp-eval man page.
regards,
-glenn
On Thu, April 28, 2016 12:22 am, Bernardo wrote:
> Hi Glenn, thanks for your answer.
>
> I tried with your proposal and gives me error:
>
> class "test" { match (option dhcp-client-identifier or hardware or
> ^
> Configuration file errors encountered -- exiting
>
> The "^" it's points to hardware. Remember that I use the version 3.1.1.
>
> Anyway, even though English is not my native language, I understand that
> pick-first-value would have to return the match as the manual says "Each
> expression is evaluated, starting with the first in
> the list, until an expression is found that does not evaluate to a null
> value.".
>
> Cheers, Bernardo.
>
> ------ Original Message ------
> From: "Glenn Satchell" < [hidden email]>
> To: "Users of ISC DHCP" < [hidden email]>
> Sent: 27/04/2016 11:07:21
> Subject: Re: Unexpected behavior with pick-first-value
>
>>Hi Bernado
>>
>>pick-first-value is working as specified. The thing to be matched
>>against
>>is the first non-null value in the list. Therefore in your first case
>>where you have:
>>
>>match pick-first-value (option dhcp-client-identifier, hardware,
>>suffix(option dhcp-client-identifier, 7));
>>
>>the thing to be matched against is option dhcp-client-identifier.
>>
>>If you want to match against any of the three you need to use match ...
>>or
>>... or ..., for example:
>>
>>match (option dhcp-client-identifier or hardware or suffix(option
>>dhcp-client-identifier, 7));
>>
>>regards,
>>-glenn
>>
>>On Wed, April 27, 2016 11:59 pm, Bernardo wrote:
>>> Hi,
>>>
>>> I running a DHCP Server version V3.1.1 and I have the following
>>> situation in which I expect that pick-first-value works in a certain
>>>way
>>> and do not get it.
>>>
>>> I have this information from DHCP for the device:
>>>
>>> Client-identifier: ff:10:08:19:d9:00:03:00:01:bc:c8:10:08:19:d9
>>> Hardware: 1:bc:c8:10:8:19:d9
>>>
>>> To obtain this information I use the following logs:
>>>
>>> log (info, concat ("Lease request from hardware ",
>>>binary-to-ascii(16,
>>> 8, ":", substring(hardware, 0, 7)), " in subnet xx"));
>>> log (info, concat ("Lease request from identifier ",
>>>binary-to-ascii(16,
>>> 8, ":", option dhcp-client-identifier), " in subnet xx"));
>>> log (info, concat ("Lease request from suffix identifier ",
>>> binary-to-ascii(16, 8, ":", suffix(option dhcp-client-identifier,
>>>7)), "
>>> in subnet xx"));
>>>
>>> And the results is:
>>>
>>> Apr 27 06:27:01 dev dhcpd: Lease request from hardware
>>> 1:bc:c8:10:8:19:d9 in subnet xx
>>> Apr 27 06:27:01 dev dhcpd: Lease request from identifier
>>> ff:10:8:19:d9:0:3:0:1:bc:c8:10:8:19:d9 in subnet xx
>>> Apr 27 06:27:01 dev dhcpd: Lease request from suffix identifier
>>> 1:bc:c8:10:8:19:d9 in subnet xx
>>>
>>> I use these very simple instructions to create a class and subclass:
>>>
>>> class "test" { match pick-first-value (option dhcp-client-identifier,
>>> hardware, suffix(option dhcp-client-identifier, 7)); }
>>> subclass "test" 1:bc:c8:10:08:19:d9 {}
>>>
>>> So, here the problem, I expect that if Client-identifier does not
>>>match
>>> try with the hardware data and then with suffix data, right, but this
>>> does not happen.
>>>
>>> I change the match for this pick-first-value (hardware, option
>>> dhcp-client-identifier) and then the device it's classified under the
>>> test class.
>>> I change the match for this pick-first-value (option
>>> dhcp-client-identifier, suffix(option dhcp-client-identifier, 7),
>>> hardware) and then the device it's not classified.
>>> I change the match for this pick-first-value (suffix(option
>>> dhcp-client-identifier, 7), option dhcp-client-identifier, hardware)
>>>and
>>> then the device it's classified under the test class.
>>>
>>> So, apparently pick-first-value classifies only when the first data
>>> matches the declared value in a subclass.
>>>
>>> I'm missing something ? It is this the behavior expected ? I copy
>>>below
>>> what the manual says regarding pick-first-value:
>>>
>>> pick-first-value (data-expr1 [ ... exprn ] )
>>>
>>> The pick-first-value function takes any number of data expressions as
>>> its arguments. Each expression is evaluated, starting with the first
>>>in
>>> the list, until an expression is found that does not evaluate to a
>>>null
>>> value. That expression is returned, and none of the subsequent
>>> expressions are evaluated. If all expressions evaluate to a null
>>>value,
>>> the null value is returned.
>>>
>>> P.S.: I have solved my problem with the last example of a match, but
>>>I
>>> wonder if I'm doing something wrong with my analysis.
>>>
>>> Greetings, Bernardo.
>>>
>>> _______________________________________________
>>> dhcp-users mailing list
>>> [hidden email]
>>> https://lists.isc.org/mailman/listinfo/dhcp-users>>>
>>
>>
>>_______________________________________________
>>dhcp-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users>
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Hi Glenn, thanks for your answer.
Yes, "if" evaluation it's discarded.
I now understood why the behavior of pick-first-value, I was
interpreting a match functionality for the purposes of comparing and
passes to the next, etc, now I see that it is not. Thanks for the
lighting :).
Cheers, Bernardo.
------ Original Message ------
From: "Glenn Satchell" < [hidden email]>
To: "Users of ISC DHCP" < [hidden email]>
Sent: 27/04/2016 11:39:28
Subject: Re: Unexpected behavior with pick-first-value
>ok, thinking more about it, that syntax won't work.
>
>However, what's happenning in your case is that the option
>dhcp-client-identifier is non-null so gets chosen but that string
>doesn't
>match the sub-class string. What it doesn't do is match any of the
>three,
>and thinking about it I can't see how you might do that without a gian
>'if' statement.
>
>It looks like you have read the dhcp-eval man page.
>
>regards,
>-glenn
>
>On Thu, April 28, 2016 12:22 am, Bernardo wrote:
>> Hi Glenn, thanks for your answer.
>>
>> I tried with your proposal and gives me error:
>>
>> class "test" { match (option dhcp-client-identifier or hardware or
>> ^
>> Configuration file errors encountered -- exiting
>>
>> The "^" it's points to hardware. Remember that I use the version
>>3.1.1.
>>
>> Anyway, even though English is not my native language, I understand
>>that
>> pick-first-value would have to return the match as the manual says
>>"Each
>> expression is evaluated, starting with the first in
>> the list, until an expression is found that does not evaluate to a
>>null
>> value.".
>>
>> Cheers, Bernardo.
>>
>> ------ Original Message ------
>> From: "Glenn Satchell" < [hidden email]>
>> To: "Users of ISC DHCP" < [hidden email]>
>> Sent: 27/04/2016 11:07:21
>> Subject: Re: Unexpected behavior with pick-first-value
>>
>>>Hi Bernado
>>>
>>>pick-first-value is working as specified. The thing to be matched
>>>against
>>>is the first non-null value in the list. Therefore in your first case
>>>where you have:
>>>
>>>match pick-first-value (option dhcp-client-identifier, hardware,
>>>suffix(option dhcp-client-identifier, 7));
>>>
>>>the thing to be matched against is option dhcp-client-identifier.
>>>
>>>If you want to match against any of the three you need to use match
>>>...
>>>or
>>>... or ..., for example:
>>>
>>>match (option dhcp-client-identifier or hardware or suffix(option
>>>dhcp-client-identifier, 7));
>>>
>>>regards,
>>>-glenn
>>>
>>>On Wed, April 27, 2016 11:59 pm, Bernardo wrote:
>>>> Hi,
>>>>
>>>> I running a DHCP Server version V3.1.1 and I have the following
>>>> situation in which I expect that pick-first-value works in a
>>>>certain
>>>>way
>>>> and do not get it.
>>>>
>>>> I have this information from DHCP for the device:
>>>>
>>>> Client-identifier: ff:10:08:19:d9:00:03:00:01:bc:c8:10:08:19:d9
>>>> Hardware: 1:bc:c8:10:8:19:d9
>>>>
>>>> To obtain this information I use the following logs:
>>>>
>>>> log (info, concat ("Lease request from hardware ",
>>>>binary-to-ascii(16,
>>>> 8, ":", substring(hardware, 0, 7)), " in subnet xx"));
>>>> log (info, concat ("Lease request from identifier ",
>>>>binary-to-ascii(16,
>>>> 8, ":", option dhcp-client-identifier), " in subnet xx"));
>>>> log (info, concat ("Lease request from suffix identifier ",
>>>> binary-to-ascii(16, 8, ":", suffix(option dhcp-client-identifier,
>>>>7)), "
>>>> in subnet xx"));
>>>>
>>>> And the results is:
>>>>
>>>> Apr 27 06:27:01 dev dhcpd: Lease request from hardware
>>>> 1:bc:c8:10:8:19:d9 in subnet xx
>>>> Apr 27 06:27:01 dev dhcpd: Lease request from identifier
>>>> ff:10:8:19:d9:0:3:0:1:bc:c8:10:8:19:d9 in subnet xx
>>>> Apr 27 06:27:01 dev dhcpd: Lease request from suffix identifier
>>>> 1:bc:c8:10:8:19:d9 in subnet xx
>>>>
>>>> I use these very simple instructions to create a class and
>>>>subclass:
>>>>
>>>> class "test" { match pick-first-value (option
>>>>dhcp-client-identifier,
>>>> hardware, suffix(option dhcp-client-identifier, 7)); }
>>>> subclass "test" 1:bc:c8:10:08:19:d9 {}
>>>>
>>>> So, here the problem, I expect that if Client-identifier does not
>>>>match
>>>> try with the hardware data and then with suffix data, right, but
>>>>this
>>>> does not happen.
>>>>
>>>> I change the match for this pick-first-value (hardware, option
>>>> dhcp-client-identifier) and then the device it's classified under
>>>>the
>>>> test class.
>>>> I change the match for this pick-first-value (option
>>>> dhcp-client-identifier, suffix(option dhcp-client-identifier, 7),
>>>> hardware) and then the device it's not classified.
>>>> I change the match for this pick-first-value (suffix(option
>>>> dhcp-client-identifier, 7), option dhcp-client-identifier,
>>>>hardware)
>>>>and
>>>> then the device it's classified under the test class.
>>>>
>>>> So, apparently pick-first-value classifies only when the first
>>>>data
>>>> matches the declared value in a subclass.
>>>>
>>>> I'm missing something ? It is this the behavior expected ? I copy
>>>>below
>>>> what the manual says regarding pick-first-value:
>>>>
>>>> pick-first-value (data-expr1 [ ... exprn ] )
>>>>
>>>> The pick-first-value function takes any number of data expressions
>>>>as
>>>> its arguments. Each expression is evaluated, starting with the
>>>>first
>>>>in
>>>> the list, until an expression is found that does not evaluate to a
>>>>null
>>>> value. That expression is returned, and none of the subsequent
>>>> expressions are evaluated. If all expressions evaluate to a null
>>>>value,
>>>> the null value is returned.
>>>>
>>>> P.S.: I have solved my problem with the last example of a match,
>>>>but
>>>>I
>>>> wonder if I'm doing something wrong with my analysis.
>>>>
>>>> Greetings, Bernardo.
>>>>
>>>> _______________________________________________
>>>> dhcp-users mailing list
>>>> [hidden email]
>>>> https://lists.isc.org/mailman/listinfo/dhcp-users>>>>
>>>
>>>
>>>_______________________________________________
>>>dhcp-users mailing list
>>> [hidden email]
>>> https://lists.isc.org/mailman/listinfo/dhcp-users>>
>> _______________________________________________
>> dhcp-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users>>
>
>
>_______________________________________________
>dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
Locked
