set doesn't work when used for client classing

Ray Phillips r.phillips at uq.edu.au
Wed Oct 21 02:16:42 UTC 2009


Since there doesn't seem to be complete information about variables 
in any of the dhc* man pages I'll quote some of Droms & Lemon, 2nd 
ed., pp. 477 - 478:

--------------------------------------------------------------------------------

The set Statement

set variable = expression;

The set statement stores the result of evaluating expression in a 
variable named variable.  This variable is recorded on the lease that 
is being processed, if a lease is being processed, and persists 
across restarts of the DHCP server.  If no lease is being processed, 
the set statement has no effect.

After a variable has been set on a lease, even the expiration of the 
lease cannot erase the variable; only the unset statement can remove 
it.  Currently only integer and string values can be stored in 
variables.  Variables are scoped to the lease, so every lease can 
have a variable with the same name, and each of these variables will 
be distinct.


The unset Statement

unset variable;

The unset statement removes the variable named variable from the 
lease that is being processed, if a lease is being processed.  If a 
lease is not being processed, this statement has no meaning.

--------------------------------------------------------------------------------


>Can somebody please let me know why set doesn't work in the following case ?
>I don't see any response from dhcpd, it should have choosen a pool 
>for class "Crule1". Even if it didn't match it should have choosen 
>from "Crule2A". But no response. Am I missing something ?
>Here is the conf file:
>subnet 192.168.1.0 netmask 255.255.255.0 {
>
>default-lease-time 86500;
>max-lease-time 86500;
>option routers 192.168.1.254;
>
>set kind = 0;
>
>if substring (option vendor-class-identifier, 0, 4) = "MSFT" {
>set kind = 1;
>} elsif substring (option dhcp-option-overload, 0, 4) = "MSFT" {
>set kind = 2;
>} elsif not exists dhcp-option-overload {
>set kind = 21;
>}

The values being assigned to the variable 'kind' here are unquoted so 
they're integer values.

>class "Crule1" {
>match if kind = "1";
>}

1 is quoted here so the variable 'kind', which contains an integer, 
is being compared to a string and the comparison fails.

I have only used string variables, so can't be sure, but it would be 
logical for the comparisons to function as intended if the quotes 
were removed in the 'match if' statements.

I haven't used string variables in 'match if' statements but 
presumably the comparisons would also work as intended if the values 
in both the 'set' and 'match if' statements were quoted.


Ray



More information about the dhcp-users mailing list