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 >> Dnsmasqfirstname.lastname@example.org >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >> _______________________________________________ Dnsmasq-discuss mailing list Dnsmasqemail@example.com http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss