[Dnsmasq-discuss] dnsmasq 2.64rc2

[Gene Czarcinski]

On 12/02/2012 06:34 AM, Gene Czarcinski wrote:
> On 12/02/2012 06:19 AM, Gene Czarcinski wrote:
>> On 12/01/2012 04:25 PM, Simon Kelley wrote:
>>> I've pushed dnsmasq-2.64rc2 at
>>>
>>> http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.64rc2.tar.gz 
>>>
>>>
>>> This adds an extra check on which interfaces router advertisements 
>>> go out on, and the SetDomainServers DBus method. This will become 
>>> 2.64 final very soon unless any problems are reported.
>>>
>> This is looking very good!  The my RTR-ADVERT problem (really the RAs 
>> from the virtual network's dnsmasq being sent to the real NIC) seem 
>> to have disappeared.  While I believe that things are fixed, I want 
>> to do a little more testing.
>>
>> In addition, I want to look at the source code as compared to 2.64rc1 
>> to see what you did.
>>
>> I do notice one change that I found a bit surprising.  With two 
>> virtual network autostarted [10:6 on virbr11 and 10:8 on virbr15], 
>> RTR-ADVERT messages are only for virbr15 [10:8].  Net6 appears OK and 
>> functions with virtual guests but far fewer RTR-ADVERT messages from 
>> it... like none.  Just saying.
>>
> Problem still exists where p33p1 is getting SLAAC addresses.
>
> When this occurs, there are no RTR-ADVERT syslog messages for the 
> network now on p33p1.  Sometimes it is only one and other times it is 
> both net6 and net8,  I doubt that this would happen with DHCPv6 
> because there has to be a server out there actually servicing that 
> network.
>
> I will keep poking around.
It is not something in dnsmasq startup because I can sit there and keep 
repeating:
   virsh net-destroy net6; virsh net-start net6
and things work correctly every time.

If I restart libvirtd and net6 and net8 were already running, then 
everything is OK because libvirtd will leave running dnsmasq alone. But, 
if I restart libvirtd and net6/net8 need to be autorestarted, then the 
problem occurs.

I also tried autostarting a different network with an DHCPv6 defined, 
and everything was OK.  It seems to only occur with ra-only IPv6 networks.

LATER...

The following uses dnsmasq 2.65rc2.

OK, I did some additional testing.  I slightly modified libvirt so that 
it required dnsmasq 2.65 to have dnsmasq do the RA service. Installed it 
and got to a steady state with net6/net8 stopped.

Started wireshark and captured data on p33p1.  Restart libvirtd.  No 
ICMPv6!  Later, I ran wireshark on virtual guest to see what radvd supplied.

The, I downgraded libvirt so that the "slight modification" was removed 
and dnsmasq did the RA service.

Got to a steady state with net6/net8 stopped.  Restart libvirtd.

You can see the results in the attached file but it appears that both 
net6 and net8 dnsmasq instances issued RAs to p33p1 and they were 
processed to add the two subnets.

All three wireshark captures are attached.

I am not sure what dnsmasq does differently than radvd but, whatever it 
does is an "undesirable feature".

I am going to continue looking but this appears to me to be a dnsmasq bug.

Do you have the impression that I might have a "reverse midas touch" 
with respect to IPv6 and dnsmasq?

Gene
-------------- next part --------------
A non-text attachment was scrubbed...
Name: falcon-dnsmasq-p33p1-1.pcapng
Type: application/octet-stream
Size: 9524 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20121202/9ac943b9/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: falcon-radvd-p33p1-1.pcapng
Type: application/octet-stream
Size: 4692 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20121202/9ac943b9/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: virt-radvd-eth0-1.pcapng
Type: application/octet-stream
Size: 8332 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20121202/9ac943b9/attachment-0005.obj>