Dealing with possible list of numeric option values (pxe-system-type)

[Boylan, Ross]

According to RFC 4578 and the dhcp-options man page, pxe-system-type has values that are a list of one or more uint16's. dhcp-eval and dhcp-options didn't seem to say exactly how I could work with it, or, more directly, what the result of using "option pxe-system-type" in a conditional expression is: a string? a number? a list?

My first guess was
if option pxe-system-type = 7 then ....
Should that work?  I notice all the examples on this list seem to use the form
if option pxe-system-type = 00:07 then ..
suggesting the values are converted to a stream of bytes after promotion to 32 bit integer size.

Further, it sounds as if there might be multiple values supplied.  Is there any good way to figure if 7 is one of them?
Will option pxe-system-type = 00:07 fail if there is more than one element returned, even if the first one is 7?
Maybe in practice it is never an issue?

I'm also curious how options that are lists with elements other than numbers work.

Thanks.
Ross Boylan
cc's appreciated
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

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

[glenn.satchell]

Hi Ross

Lists are encoded as a byte stream of concatenated values, so a list of
int32 would be groups of 4 bytes, int16 as groups of 2 bytes, etc.

You might be able to use the regex match to pick a value in the
subsequent byte stream, regex is defined in dhcp-eval as

data-expression-1 ~= data-expression-2

such as

if option pxe-system-type ~= 00:07 then ...

I haven't tested this, so you may want to verify my suggestion.

regards,
Glenn

On 2020-11-16 15:22, Boylan, Ross wrote:

> According to RFC 4578 and the dhcp-options man page, pxe-system-type
> has values that are a list of one or more uint16's. dhcp-eval and
> dhcp-options didn't seem to say exactly how I could work with it, or,
> more directly, what the result of using "option pxe-system-type" in a
> conditional expression is: a string? a number? a list?
>
> My first guess was
> if option pxe-system-type = 7 then ....
> Should that work?  I notice all the examples on this list seem to use
> the form
> if option pxe-system-type = 00:07 then ..
> suggesting the values are converted to a stream of bytes after
> promotion to 32 bit integer size.
>
> Further, it sounds as if there might be multiple values supplied.  Is
> there any good way to figure if 7 is one of them?
> Will option pxe-system-type = 00:07 fail if there is more than one
> element returned, even if the first one is 7?
> Maybe in practice it is never an issue?
>
> I'm also curious how options that are lists with elements other than
> numbers work.
>
> Thanks.
> Ross Boylan
> cc's appreciated
> _______________________________________________
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

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

[Simon Hobson]

[hidden email] wrote:

> Lists are encoded as a byte stream of concatenated values, so a list of int32 would be groups of 4 bytes, int16 as groups of 2 bytes, etc.
>
> You might be able to use the regex match to pick a value in the subsequent byte stream, regex is defined in dhcp-eval as
>
> data-expression-1 ~= data-expression-2
>
> such as
>
> if option pxe-system-type ~= 00:07 then ...
>
> I haven't tested this, so you may want to verify my suggestion.

It may be fine in this case, but in the general case you need to be careful not to have false matches across options. E.g. if there were two options of (say) ff:00 and 07:1f (in that order) then neither option is 00:07, but if you do an unconstrained regex match then it would detect 00:07.

I suppose one way would be to do a match along the lines of :
substr(option,0,2)=00:07 or substr(option,2,2)=00:07 or ... or substr(option,2n,2)=00:07

But then you can quickly get into a bit of a mess, and are still hardcoding a specific limit in number of values you will search through.

There is a bigger issue if an option is not made up of elements that are all the same set length - and I think that would need external processing to split out individual elements.

Simon

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

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