Unexpected behavior with pick-first-value

[Glenn Satchell]

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
>