[Dnsmasq-discuss] [libvirt] [PATCHv3 1/2] network: added waiting for DAD to finish for bridge address.

[Laine Stump]

On 08/11/2015 04:14 AM, Simon Kelley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 10/08/15 22:29, Laine Stump wrote:
>> On 08/10/2015 01:08 PM, Maxim Perevedentsev wrote:
>>> This is a fix for commit
>>> db488c79173b240459c7754f38c3c6af9b432970 dnsmasq main process
>>> exits without waiting for DAD, this is dnsmasq daemon's task. So
>>> we periodically poll the kernel using netlink and check whether
>>> there are any IPv6 addresses assigned to bridge which have
>>> 'tentative' state. After DAD is finished, execution continues. I
>>> guess that is what dnsmasq was assumed to do.
>> Since the comments in our code imply that dnsmasq should be waiting
>> for DAD to complete prior to daemonizing, before pushing a fix like
>> this I'd like to find out from the dnsmasq folks if we are
>> erroneously relying on nonexistent dnsmasq behavior, or if maybe
>> there is a bug in some version of dnsmasq.
>>
>> Simon (or other dnsmasq people) - when dnsmasq is run with
>> "enable-ra", does it make sure it completes DAD prior to
>> daemonizing? Or does libvirt need to do this extra polling to
>> assure that DAD has completed? (or maybe there's some other config
>> parameter we need to add?)
>>
>>
> Dnsmasq doesn't wait for DAD to complete before returning. Internally,
> it know is DAD is still happening on an interface, as it needs to
> delay calling bind() until after it's complete. It would, therefore be
> relatively simple to add this behaviour, but it's not a complete
> solution, since new interfaces can appear _after_ dnsmasq has
> completed start-up.
>
> Having libvirt do its own checks whenever it creates an interface
> might therefore be a cleaner way of doing things, but I don't have an
> objection to changing dnsmasq behaviour if there's a good reason why
> that's not sensible.

No need for dnsmasq to change its behavior. I just wanted to make sure
that it was the comment in libvirt that was wrong, and not a regression
in dnsmasq. Based on your answer, it appears that this was a
misunderstanding by the original author of the libvirt code, so it is
something that libvirt needs to fix.

Thanks for the quick response!