[Dnsmasq-discuss] Gotcha!

Gene Czarcinski gene at czarc.net
Sat Dec 1 21:02:32 GMT 2012


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.

Gene



More information about the Dnsmasq-discuss mailing list