[Dnsmasq-discuss] Gotcha!

Simon Kelley simon at thekelleys.org.uk
Sat Dec 1 21:20:10 GMT 2012


On 01/12/12 21:02, 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.
>


Agreed, checking the interface is the right thing to do (I'm preparing 
2.64rc2 with this right now) but it's patching a problem, which is that 
dnsmasq is advertising the 10:6 network on a virbr interface, and that 
advert (or maybe a DHCP offer) is being seen by the p33pl interface, 
which is then being configured with a 10:6 address. Once this happens, 
dnsmasq starts sending adverts down p33pl too, because is has the 10:6 
address, but that's a symptom, not a cause.


Simon.



More information about the Dnsmasq-discuss mailing list