Unexpected behavior with pick-first-value

[Bernardo]

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