[Dnsmasq-discuss] [BUG] RA are sent too fast and slows down the machine

Maarten de Vries maarten+dnsmasq at m.de-vri.es
Tue Aug 27 21:42:38 BST 2019


I haven't dug very deep yet, but I can comment on the intent of the 
particular commit: without it, dnsmasq didn't do any unsolicited RAs on 
interfaces that are created after dnsmasq was started. It definitely 
should do unsolicited RAs on those interfaces too, although obviously 
not quite so many so often. I'm not sure why that happens. Note that the 
commit didn't introduce the fast RAs, it only enabled unsolicited RAs 
(including fast) for newly created interfaces too.

I wonder why this happens in those test cases and at-least one Raspberry 
Pi, but not on my server. Is there any information you could provide to 
pinpoint when exactly this bug triggers and when not? For example: what 
happens if the virtual interface is created before dnsmasq starts? Does 
it also trigger on bridge interfaces (which is what I personally tested 
the commit with) for you?

I will attempt to investigate too, but I'm somewhat swamped for time so 
I can't promise fast results.

Kinds regards,


On 27-08-2019 10:45, Iain Lane wrote:
> On Wed, Aug 21, 2019 at 08:59:07PM +0200, Petr Mensik wrote:
>> Hi Simon and Maarten,
>> we discovered when playing with NetworkManager-ci [1], that lastest
>> release is somehow broken. Test running dnsmasq are quite slow on latest
>> release.
>> I have created repeatable started script that reproduces it. Then used
>> git bisect to find when it was broken. It seems fast sending were
>> intentional in commit 0a496f059c1e9 [2], but maybe way it affects the
>> system were underestimated. It is significant for systems that hit such
>> issue. I think it has to be fixed to slow it down to short time
>> interval, not endless loop. Reported as Fedora bug [3].
> Thanks for this Petr. Would you be able to share the script you've used,
> so that perhaps an upstream developer could recreate the bug?
> Mainly I wanted to chime in and say that (in addition to the other
> instance referenced), we found this in the NetworkManager testsuite in
> Ubuntu. I didn't come up with a nice reproducer at the time, but we did
> identify the same commit and we've reverted it in Ubuntu. I posted on
> the ML back then but we didn't get much traction and I didn't follow up
> very aggressively.
>    http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q4/012709.html
>    https://launchpadlibrarian.net/405377161/dnsmasq_2.80-1_2.80-1ubuntu1.diff.gz
>    (the commit ID referenced in the changelog there seems or from
>    somewhere else, it's the same patch)
> Cheers,
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20190827/f03de395/attachment.html>

More information about the Dnsmasq-discuss mailing list