[Dnsmasq-discuss] Gotcha!

Simon Kelley simon at thekelleys.org.uk
Sat Dec 1 21:28:30 GMT 2012


On 01/12/12 21:21, Gene Czarcinski wrote:
> On 12/01/2012 04:02 PM, Gene Czarcinski wrote:
>> On 12/01/2012 03:36 PM, Gene Czarcinski wrote:
>>> Well, I seem to be able to create the problem at will!
>>>
>>> I created a small patch (attached) to instrument things. The result
>>> was that BOTH autostarted networks got screwed up! The syslog is also
>>> attached. Here is the output of ip addr which show not one but TWO
>>> bad addresses on it [10:6 and 10:8]:
>>>
>>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
>>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>> inet 127.0.0.1/8 scope host lo
>>> inet6 ::1/128 scope host
>>> valid_lft forever preferred_lft forever
>>> 2: p33p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
>>> state UP qlen 1000
>>> link/ether 30:85:a9:8f:e9:82 brd ff:ff:ff:ff:ff:ff
>>> inet 192.168.17.2/24 brd 192.168.17.255 scope global p33p1
>>> inet6 fd00:beef:10:6:3285:a9ff:fe8f:e982/64 scope global dynamic
>>> valid_lft 7135sec preferred_lft 7135sec
>>> inet6 fd00:beef:10:8:3285:a9ff:fe8f:e982/64 scope global dynamic
>>> valid_lft 7172sec preferred_lft 7172sec
>>> inet6 fd00:dead:beef:17:1::2/128 scope global
>>> valid_lft forever preferred_lft forever
>>> inet6 fe80::3285:a9ff:fe8f:e982/64 scope link
>>> valid_lft forever preferred_lft forever
>>>
>>> Here is what I believe is the solution (it is pretty much in the
>>> patch). In periodic_ra() [radv.c], a test needs to be added so that
>>> if the send_ra() is to go to an interface which is NOT ours, don't do
>>> it ... "ours" being defined by any interface=<ip6addr>
>>>
>>> My next step is to give this a try.
>>>
>>> I do not know if this is the absolutely right fix because I am not
>>> sure I understand how p33p1 got queued up for this dnsmasq instance.
>>>
>>> Any insight appreciated.
>>>
>> Getting close but not a winner yet. I am not bothering to add any more
>> syslog, etc. as it is essentially the same.
>>
>> This time, the 10:6 network was OK but the 10:8 network was not. I
>> need to go back up the chain of things to find out what happens in the
>> first place.
>>
>> Oh yes, I detected the bad interface name but just not sending the RA
>> is not good enough. Using ip addr shows the SLAAC
>> fd00:beef:10:8::3285:a9ff:fe8f:e982/64 address on the interface.
>>
>> I believe that checking the interface names against what is specified
>> is the correct thing to do, it just needs to be in exactly the "right"
>> place in the code.
>>
>> I do not want to touch the libvirt code so that I have something
>> consistent to test with (and rebuilding the dnsmasq rpm takes all of
>> 10 seconds). But, I may add something which will force bind-interfaces
>> when bind-dynamic is specified just to see if that changes anything.
> Not conclusive but promising. I will need to modify libvirt slightly so
> that it uses bind-interfaces, interface=<if_name>, except-interface=lo
>

If you move from bind-dynamic back to bind-interfaces, you'll 
re-introduce the "open DNS server" security bug.


Simon.



More information about the Dnsmasq-discuss mailing list