[Dnsmasq-discuss] Config file behaviour - change/bug/feature - comments

[Simon Kelley]

On 28/03/13 16:02, Kevin Darbyshire-Bryant wrote:
> On 28/03/2013 13:42, Simon Kelley wrote:
>> On 28/03/13 13:14, Kevin Darbyshire-Bryant wrote:
>>> On 28/03/2013 12:58, Simon Kelley wrote:
>>>> On 28/03/13 12:26, Kevin Darbyshire-Bryant wrote:
>>>>> I'm led to believe that v2.61 behaves as 'last instance sticks'  I
>>>>> know that 2.66rc2 still has first instance sticks. Maybe that helps.
>>>>
>>>> OK, I'm confused. Are we just talking about --interface , or
>>>> --no-dhcp-interface too?
>>>>
>>>> For both 2.61 and 2.66
>>>>
>>>
>>> Apologies Simon, I've not stated the 'problem' clearly, mainly because
>>> I've had conflicting reports of problems/workarounds/solutions.  The
>>> final 'problem' is as follows:
>>>
>>> If I have a config file that defines a dhcp option twice then in v2.61
>>> the last instance of that same option sticks, whereas in 2.66test16 &
>>> rc2 the first instance sticks and subsequent re-definitions get ignored.
>>>
>>> eg:
>>>
>>> dhcp-range=br0,192.168.235.21,192.168.235.254,255.255.255.0,720m
>>> dhcp-option=br0,3,192.168.235.1
>>> dhcp-option=br0,44,0.0.0.0
>>> ...
>>> ...
>>> dhcp-option=br0,3,192.168.235.254
>>>
>>> in 2.61, option 3 is 192.168.235.254, in 2.66 it stays as 192.168.235.1
>>>
>>> In the situation where a router config gui has configured the first part
>>> of the file and then someone wishes to manually append custom stuff
>>> (again accessible via the gui) then in 2.66 overrides are no longer
>>> possible.  So a human wouldn't generate a config file such as above, but
>>> an automated idiot may :-)
>>>
>>
>> OK, that makes more sense, though I'm not sure why the change, again
>> it's not been deliberate. This is undefined behaviour though, so it's
>> more understandable that it's changed.
>>
>> I think there's an easy workaround: Just remove the tag from the first
>> definition of option 3, so
>>
>> dhcp-option=br0,3,192.168.235.1 becomes dhcp-option=3,192.168.235.1
>>
>> It _is_ defined that if there are two available values for an option,
>> one with tag(s) and one with no tags, then the one with tags wins.
>> (provided matching tags are set, of course).
>>
>>
>> Cheers,
>>
>> Simon.
>>
>>
>>
>>
>
> Ahh, but there's the rub, the first instance of dhcp-option=br0,.......
> is generated automatically by the router software and cannot be changed,
> it's why we need to be able to override it.

Ok. will have to think harder about this, in that case.

>
> But I'm now concerned about your previous email where I think interfaces
> have been removed.  Is it no longer possible to define dhcp range &
> options on an interface by interface basis?

No. The interface:<interface> thing in dhcp-range is/was something else. 
If you were not using that specific syntax, then there's no problem.

Cheers,

Simon.

>
> Kevin
>