[Dnsmasq-discuss] Question about the behavior of options 66 and 67

[Shankar Unni]

One of our users ran into an interesting issue.

They have IP phones that explicitly request options 66 and 67 as part of their DHCP Parameter Request List of the DISCOVER/REQUEST, but still expect the resultant OFFER/ACK to return those values in the “sname” and “file” fields (within the “bootp” portion of the packet), rather than as DHCP Options. (I guess they don’t care if the response also contains them as Options, but they definitely only look for these values in the sname and file fields).

Dnsmasq seems to behave differently: if the client asks for 66 or 67, they always get them back as DHCP Options (and sname and file are left empty); if they don’t ask (but the server is configured for these options), then dnsmasq stuffs them into the “sname” and “file” fields. (Other vendors they use, however - like Cisco Meraki and Aricent - seem to behave the way I described in the previous paragraph.)

Is this a deliberate choice? Is there any way to get dnsmasq to do what these IP phones seem to expect (i.e. always stuff options 66 and 67 into sname and file, regardless of whether they are asked for as DHCP options)?

Thanks in advance!

- --
Shankar

[Simon Kelley]

This dnsmasq configuration is relevant:

--dhcp-no-override
(IPv4 only) Disable re-use of the DHCP servername and filename
fields as extra option space. If it can, dnsmasq moves the boot
server and filename information (from --dhcp-boot) out of their
dedicated fields into DHCP options. This make extra space avail‐
able in the DHCP packet for options but can, rarely, confuse old
or broken clients. This flag forces "simple and safe" behaviour
to avoid problems in such a case.


Note the mention of --dhcp-boot. If you're specifying these
--dhcp-option=66,.....
then and the client requests options 66 and 67 then they'll still be
sent as options, and not in the dedicated fields, so you need to use
--dhcp-boot to specify them.

Cheers,

Simon

Post by Shankar Unni
One of our users ran into an interesting issue.
They have IP phones that explicitly request options 66 and 67 as part of their DHCP Parameter Request List of the DISCOVER/REQUEST, but still expect the resultant OFFER/ACK to return those values in the “sname” and “file” fields (within the “bootp” portion of the packet), rather than as DHCP Options. (I guess they don’t care if the response also contains them as Options, but they definitely only look for these values in the sname and file fields).
Dnsmasq seems to behave differently: if the client asks for 66 or 67, they always get them back as DHCP Options (and sname and file are left empty); if they don’t ask (but the server is configured for these options), then dnsmasq stuffs them into the “sname” and “file” fields. (Other vendors they use, however - like Cisco Meraki and Aricent - seem to behave the way I described in the previous paragraph.)
Is this a deliberate choice? Is there any way to get dnsmasq to do what these IP phones seem to expect (i.e. always stuff options 66 and 67 into sname and file, regardless of whether they are asked for as DHCP options)?
Thanks in advance!
- --
Shankar
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Shankar Unni]

Thanks, Simon!

I did discover this and figured out that we can specify it as —dhcp-boot=… and —dhcp-no-override. But then these options will ALWAYS only be sent as bootp fields, right?

Will there be an issue the other way, then? (I.e. some client that sends in options 66/67 in parameter request list and definitely expects them in the resultant DHCP options?) Is there a way to make dnsmasq populate both (i.e. the bootp fields as well as DHCP option entries for 66 and 67?

I’m hoping not, and will explore the use of —dhcp-boot..

Post by Simon Kelley
--dhcp-no-override
(IPv4 only) Disable re-use of the DHCP servername and filename
fields as extra option space. If it can, dnsmasq moves the boot
server and filename information (from --dhcp-boot) out of their
dedicated fields into DHCP options. This make extra space avail‐
able in the DHCP packet for options but can, rarely, confuse old
or broken clients. This flag forces "simple and safe" behaviour
to avoid problems in such a case.
Note the mention of --dhcp-boot. If you're specifying these
--dhcp-option=66,.....
then and the client requests options 66 and 67 then they'll still be
sent as options, and not in the dedicated fields, so you need to use
--dhcp-boot to specify them.
Cheers,
Simon

Post by Shankar Unni
One of our users ran into an interesting issue.
They have IP phones that explicitly request options 66 and 67 as part of their DHCP Parameter Request List of the DISCOVER/REQUEST, but still expect the resultant OFFER/ACK to return those values in the “sname” and “file” fields (within the “bootp” portion of the packet), rather than as DHCP Options. (I guess they don’t care if the response also contains them as Options, but they definitely only look for these values in the sname and file fields).
Dnsmasq seems to behave differently: if the client asks for 66 or 67, they always get them back as DHCP Options (and sname and file are left empty); if they don’t ask (but the server is configured for these options), then dnsmasq stuffs them into the “sname” and “file” fields. (Other vendors they use, however - like Cisco Meraki and Aricent - seem to behave the way I described in the previous paragraph.)
Is this a deliberate choice? Is there any way to get dnsmasq to do what these IP phones seem to expect (i.e. always stuff options 66 and 67 into sname and file, regardless of whether they are asked for as DHCP options)?
Thanks in advance!
- --
Shankar
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Simon Kelley]

Post by Shankar Unni
Thanks, Simon!
I did discover this and figured out that we can specify it as —dhcp-boot=… and —dhcp-no-override. But then these options will ALWAYS only be sent as bootp fields, right?
Will there be an issue the other way, then? (I.e. some client that sends in options 66/67 in parameter request list and definitely expects them in the resultant DHCP options?) Is there a way to make dnsmasq populate both (i.e. the bootp fields as well as DHCP option entries for 66 and 67?

I think is you specify dhcp boot and dhcp-bo-override and dhcp-option
fro 66 and 67 then the data will always be sent in the bootp fields, and
will be sent as options if requested. Experiment needed to be sure.


Like a lot of DHCP, this is a delicate balance of working around
mutually incompatible sets of "odd" client behaviour.


Cheers,

Simon.

Post by Shankar Unni
I’m hoping not, and will explore the use of —dhcp-boot..

Post by Simon Kelley
--dhcp-no-override
(IPv4 only) Disable re-use of the DHCP servername and filename
fields as extra option space. If it can, dnsmasq moves the boot
server and filename information (from --dhcp-boot) out of their
dedicated fields into DHCP options. This make extra space avail‐
able in the DHCP packet for options but can, rarely, confuse old
or broken clients. This flag forces "simple and safe" behaviour
to avoid problems in such a case.
Note the mention of --dhcp-boot. If you're specifying these
--dhcp-option=66,.....
then and the client requests options 66 and 67 then they'll still be
sent as options, and not in the dedicated fields, so you need to use
--dhcp-boot to specify them.
Cheers,
Simon

Post by Shankar Unni
One of our users ran into an interesting issue.
They have IP phones that explicitly request options 66 and 67 as part of their DHCP Parameter Request List of the DISCOVER/REQUEST, but still expect the resultant OFFER/ACK to return those values in the “sname” and “file” fields (within the “bootp” portion of the packet), rather than as DHCP Options. (I guess they don’t care if the response also contains them as Options, but they definitely only look for these values in the sname and file fields).
Dnsmasq seems to behave differently: if the client asks for 66 or 67, they always get them back as DHCP Options (and sname and file are left empty); if they don’t ask (but the server is configured for these options), then dnsmasq stuffs them into the “sname” and “file” fields. (Other vendors they use, however - like Cisco Meraki and Aricent - seem to behave the way I described in the previous paragraph.)
Is this a deliberate choice? Is there any way to get dnsmasq to do what these IP phones seem to expect (i.e. always stuff options 66 and 67 into sname and file, regardless of whether they are asked for as DHCP options)?
Thanks in advance!
- --
Shankar
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Shankar Unni]

Post by Simon Kelley
I think is you specify dhcp boot and dhcp-bo-override and dhcp-option
fro 66 and 67 then the data will always be sent in the bootp fields, and
will be sent as options if requested. Experiment needed to be sure.
Like a lot of DHCP, this is a delicate balance of working around
mutually incompatible sets of "odd" client behaviour.

True, that. Thanks for the pointers - I’ll experiment with them and see if they meet this customer’s needs..