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..

> On Jul 25, 2018, at 10:11 AM, Simon Kelley <si...@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@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>> 


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

Reply via email to