Unexpected behavior with pick-first-value

[Glenn Satchell]

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" <glenn.satchell at uniq.com.au>
> To: "Users of ISC DHCP" <dhcp-users at lists.isc.org>
> 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
>>>  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
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>