Patch below is untested because I'm away from my test rig, but it would seem to do the right thing, ie set template->if_index _before_ calling ra_start_unsolicited() so that if we re-enter here via an async event it doesn't get called again.
If you could test it in your harness, that would be great :)
Cheers,
Simon.
diff --git a/src/dhcp6.c b/src/dhcp6.c
index 3932cc7..4082504 100644
--- a/src/dhcp6.c
+++ b/src/dhcp6.c
@@ -650,12 +650,11 @@ static int construct_worker(struct in6_addr
*local, int prefix,
/* First time found, do fast RA. */
if (template->if_index != if_index ||
!IN6_ARE_ADDR_EQUAL(&template->local6, local))
{
+ template->if_index = if_index;
+ template->local6 = *local;
ra_start_unsolicited(param->now, template);
param->newone = 1;
}
-
- template->if_index = if_index;
- template->local6 = *local;
}
}
On 20/12/2018 17:21, Iain Lane wrote:
> On Thu, Dec 20, 2018 at 01:06:30PM +0000, Iain Lane wrote:
>> dnsmasq-dhcp[2010]: RTR-ADVERT(veth42) 2600::
>>
>> repeating over and over. You can view a log file including all the
>> dnsmasq log entries at [2] - it's huge though, so I suggest downloading
>> it and using a real text editor instead of your browser.
>>
>> This test starts dnsmasq in ra-only mode, and that seems to be the case
>> that's broken. Since this started happening in a new version, I was able
>> to bisect 2.79 to 2.80, and I found that commit
>> 0a496f059c1e9d75c33cce4c1211d58422ba4f62 is the first bad commit.
>> Indeed, reverting that on master causes the NM testsuite to start
>> passing again.
>
> I attached gdb to dnsmasq while it was doing this. Here's the stack
> trace of what was going on at the time:
>
> (gdb) bt
> #0 0x00007fb1b5a7cfd4 in __GI___libc_write (fd=10, buf=0x55c255462ce8,
> nbytes=62) at ../sysdeps/unix/sysv/linux/write.c:26
> #1 0x000055c253c4fb94 in log_write () at log.c:179
> #2 0x000055c253c502fd in my_syslog (priority=6, format=0x55c253c77e39
> "RTR-ADVERT(%s) %s") at log.c:389
> #3 0x000055c253c5de2e in add_prefixes (local=0x55c25545d65c, prefix=64,
> scope=0, if_index=13, flags=4, preferred=3600, valid=3600,
> vparam=0x7ffcd1e77ce0) at radv.c:725
> #4 0x000055c253c493a0 in iface_enumerate (family=10, parm=0x7ffcd1e77ce0,
> callback=0x55c253c5d829 <add_prefixes>) at netlink.c:268
> #5 0x000055c253c5cad4 in send_ra_alias (now=1545314006, iface=13,
> iface_name=0x7ffcd1e77e1c "veth42", dest=0x0, send_iface=13)
> at radv.c:291
> #6 0x000055c253c5d826 in send_ra (now=1545314006, iface=13,
> iface_name=0x7ffcd1e77e1c "veth42", dest=0x0) at radv.c:553
> #7 0x000055c253c5e0f8 in periodic_ra (now=1545314006) at radv.c:808
> #8 0x000055c253c3e256 in lease_update_file (now=1545314006) at lease.c:355
> #9 0x000055c253c52e7e in dhcp_construct_contexts (now=1545314006) at
> dhcp6.c:789
> #10 0x000055c253c36812 in newaddress (now=1545314006) at network.c:1721
> #11 0x000055c253c39902 in async_event (pipe=8, now=1545314006) at
> dnsmasq.c:1413
> #12 0x000055c253c38e71 in main (argc=11, argv=0x7ffcd1e78258) at
> dnsmasq.c:1084
>
> There's a few places you can get an async_event of EVENT_NEWADDR. Some
> further grubbing around shows that it's coming from iface_enumerate() ->
> nl_async() -> async_event(EVENT_NEWADDR).
>
> You'll see that iface_enumerate() is frame #4 in that trace too, so this
> smells like it might be a source of infinite recursion to me: every time
> we call add_prefixes() we also queue another call of the same thing -
> the new code is to blame via dhcp_construct_contexts() calling
> construct_worker() to enter the new block setting param->newone = 1,
> which is checked in dhcp_construct_options().
>
> What's not clear to me is how best to cut this off. If we only called
> the new code one time that would probably solve it...
>
> Cheers,
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
