Problem with custom variable in bootfile-name

[Thomas Novin]

Hello

In a class I’m trying to set option bootfile-name containing both a custom-set variable (model) and some text. I’m joining these with concat. But, when I use this custom variable the concat doesn’t work. If I instead use a workaround, using the option vendor-class-identifier itself as a substring, it works. But this doesn’t practically work for me because the VCI has different prefixes depending on SW version on the client. So I need to use my own variable which I can set via a regexp match on the VCI.

        class "6450_auto" {

        match if option vendor-class-identifier ~= "OS6450" and not exists agent.circuit-id;

        max-lease-time 301;

        option tftp-server-name "1.1.1.1";

        option domain-name "6450.auto";

        # Set model based on reported vendor-class-identifier

        if option vendor-class-identifier ~= "OS6450-10" {

                set model = "6450-10";

        }

        if option vendor-class-identifier ~= "OS6450-24" {

                set model = "6450-24";

        }

        if option vendor-class-identifier ~= "OS6450-48" {

                set model = "6450-48";

        }

        option bootfile-name = concat("instruction/", model, ".alu”);

        #option bootfile-name = concat("instruction/", substring(option vendor-class-identifier, 13, 19), ".alu");

        }

One one more strangeness: dhcpd does NOT send the configured domain-name, can that depend on the client, whether it requests it or not?

Daemon version is 4.2.5 running on a CentOS 6 server.

Rgds//Thomas

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Thomas Novin]

>         if option vendor-class-identifier ~= "OS6450-48" {

>                 set model = "6450-48";

>         }

> 

>         option bootfile-name = concat("instruction/", model, ".alu”);

> 

If I use the variable in a execute-statement, it works having a mix of variables and text. Without using concat. But that does not work in an option.

For example:

                execute ("/usr/local/bin/create_instruction", model);

I have tested skipping concat in bootfile-name but that did not work. But why is it not possible to use a set variable in an option-statement.. if anyone can answer this I’d be thankful!

Rgds//Thomas

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Thomas Novin]

>>         if option vendor-class-identifier ~= "OS6450-48" {

>>                 set model = "6450-48";

>>         }

>> 

>>         option bootfile-name = concat("instruction/", model, ".alu”);

>> 

>

>If I use the variable in a execute-statement, it works having a mix of variables and text. Without using concat. But that does not work in an option.

>

>For example:

>

>                execute ("/usr/local/bin/create_instruction", model);

>

>I have tested skipping concat in bootfile-name but that did not work. But why is it not possible to use a set variable in an option-statement.. if anyone can answer this I’d be thankful!

Above I used ‘set model = “6450-48”’. I have also tried just ‘model = “6450-48”;’ but the same result, the server starts fine but it does not send any bootfile-name. So the concat probably evaluates the variable as empty and because of this the whole concat returns null. 

>>One one more strangeness: dhcpd does NOT send the configured domain-name, can that depend on the client, whether it requests it or not?

I fixed this by forcing the option on the client:

        # 1=subnet, 3=router, 12=hostname, 15=domain-name, 66=tftp-server-name, 67=bootfile-name

        option dhcp-parameter-request-list 1,3,12,15,66,67;

Rgds//Thomas

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Bob Harold]

On Tue, Jun 23, 2015 at 8:25 AM, Thomas Novin <[hidden email]> wrote:

>>         if option vendor-class-identifier ~= "OS6450-48" {

>>                 set model = "6450-48";

>>         }

>> 

>>         option bootfile-name = concat("instruction/", model, ".alu”);

>> 

>

>If I use the variable in a execute-statement, it works having a mix of variables and text. Without using concat. But that does not work in an option.

>

>For example:

>

>                execute ("/usr/local/bin/create_instruction", model);

>

>I have tested skipping concat in bootfile-name but that did not work. But why is it not possible to use a set variable in an option-statement.. if anyone can answer this I’d be thankful!

Above I used ‘set model = “6450-48”’. I have also tried just ‘model = “6450-48”;’ but the same result, the server starts fine but it does not send any bootfile-name. So the concat probably evaluates the variable as empty and because of this the whole concat returns null. 

>>One one more strangeness: dhcpd does NOT send the configured domain-name, can that depend on the client, whether it requests it or not?

I fixed this by forcing the option on the client:

        # 1=subnet, 3=router, 12=hostname, 15=domain-name, 66=tftp-server-name, 67=bootfile-name

        option dhcp-parameter-request-list 1,3,12,15,66,67;

Rgds//Thomas

The DHCP server only sends the options that the client asks for.

-- 

Bob Harold

 

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Peter Rathlev]

On Tue, 2015-06-23 at 11:39 +0000, Thomas Novin wrote:

> If I use the variable in a execute-statement, it works having a mix of
> variables and text. Without using concat. But that does not work in an
> option.
>
> For example:
>  
>    execute ("/usr/local/bin/create_instruction", model);
>
> I have tested skipping concat in bootfile-name but that did not work.
> But why is it not possible to use a set variable in an
> option-statement.. if anyone can answer this I’d be thankful!

You should be able to do it this way:

  option X-model code 254 = string;

  if option vendor-class-identifier ~= "OS6450-48" {
      option X-model "6450-48";
  }
 
  option bootfile-name = concat("instruction/", config-option X-model, ".alu”);

This is what we're using to hand out subnet specific bootfile-names. In
our case the config-option is set in each subnet and the option value is
set in a global class that matches on vendor-class-identifier.

The code points 224 through 254 are "private use". Beware that certain
systems make use of these, e.g. Windows using code 252 for WPAD related
configuration.

--
Peter


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Thomas Novin]

>You should be able to do it this way:
>
>  option X-model code 254 = string;
>
>  if option vendor-class-identifier ~= "OS6450-48" {
>      option X-model "6450-48";
>  }
>  
>  option bootfile-name = concat("instruction/", config-option X-model,
>".alu²);
>
>This is what we're using to hand out subnet specific bootfile-names. In
>our case the config-option is set in each subnet and the option value is
>set in a global class that matches on vendor-class-identifier.
>
>The code points 224 through 254 are "private use". Beware that certain
>systems make use of these, e.g. Windows using code 252 for WPAD related
>configuration.
>
>--
>Peter

Thanks! Worked perfectly.

Rgds//Thomas


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Niall O'Reilly]

On Tue, 23 Jun 2015 13:43:38 +0100,
Bob Harold wrote:
>
> The DHCP server only sends the options that the client asks for.

  ISTR over-riding the 'dhcp-parameter-request-list' option on the
  server, and thereby forcing delivery of options not actually
  requested by the client.

  It's difficult for me to check just now.  If I can do so over the
  next couple of days, I'll confirm or apologize.

  Best regards,
  Niall O'Reilly
 
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Peter Rathlev]

On Tue, 2015-06-23 at 21:43 +0100, Niall O'Reilly wrote:
> On Tue, 23 Jun 2015 13:43:38 +0100, Bob Harold wrote:
> > The DHCP server only sends the options that the client asks for.
>
> ISTR over-riding the 'dhcp-parameter-request-list' option on the
> server, and thereby forcing delivery of options not actually
> requested by the client.

Yes, that's an option:

https://lists.isc.org/pipermail/dhcp-users/2013-September/017193.html

  class "msft-wpad" {
    match if substring(option vendor-class-identifier, 0, 4) = "MSFT";
    option dhcp-parameter-request-list = concat(option dhcp-parameter-request-list, fc);
  }

This sends option 252 (0xfc) to Windows client, preventing them from
spamming with INFORMS later.

--
Peter


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Bob Harold]

On Wed, Jun 24, 2015 at 3:11 AM, Peter Rathlev <[hidden email]> wrote:

On Tue, 2015-06-23 at 21:43 +0100, Niall O'Reilly wrote:
> On Tue, 23 Jun 2015 13:43:38 +0100, Bob Harold wrote:
> > The DHCP server only sends the options that the client asks for.
>
> ISTR over-riding the 'dhcp-parameter-request-list' option on the
> server, and thereby forcing delivery of options not actually
> requested by the client.

Yes, that's an option:

https://lists.isc.org/pipermail/dhcp-users/2013-September/017193.html

  class "msft-wpad" {
    match if substring(option vendor-class-identifier, 0, 4) = "MSFT";
    option dhcp-parameter-request-list = concat(option dhcp-parameter-request-list, fc);
  }

This sends option 252 (0xfc) to Windows client, preventing them from
spamming with INFORMS later.

--
Peter

I would have expected a client to ask for all the options that it understands, and to ignore any option it did not request.  Am I missing something?

 

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Niall O'Reilly]

On Wed, 24 Jun 2015 12:32:37 +0100,
Bob Harold wrote:
> I would have expected a client to ask for all the options that it
> understands, and to ignore any option it did not request. Am I missing
> something?

  Exceptions.

  The client may avoid asking for some options which are not needed
  at boot-time.  If an application or service needs such an option at
  run-time, it will have to ask for them then (using DHCPINFORM, as
  Peter mentioned).

  The client may be "interestingly broken" and not ask even for the
  minimal set of options necessary to connect to any network.

  The network environment may need the client to be configured with
  options which are outside the set of typically sufficient ones.

  Best regards,
  Niall O'Reilly
 
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users