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

[Simon Kelley]

On 25/07/18 19:03, Shankar Unni wrote:
> 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.

> I’m hoping not, and will explore the use of —dhcp-boot..
> 
>> On Jul 25, 2018, at 10:11 AM, Simon Kelley <simon at thekelleys.org.uk> wrote:
>>
>> 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
>>
>>
>>
>>
>> On 24/07/18 21:31, Shankar Unni wrote:
>>> 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
>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>