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