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

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

Reply via email to