CARP seems to be broken with IPv6 on today's -current. When an inet6 address is configured on a carp interface, it panics the first time it tries to send an advertisement: panic: _mtx_lock_sleep: recursed on non-recursive mutex carp_if _at_ ../../../netinet/ip_carp.c:1191 The traceback looks like this: #14 0xc05c4a65 in carp_macmatch6 (v=0xc6a71500, m=0xc6646700, taddr=0xc6b3449c) at ../../../netinet/ip_carp.c:1191 #15 0xc060414c in nd6_na_output (ifp=0xc64c7000, daddr6_0=0xe4fabbc4, taddr6=0xc6b3449c, flags=32, tlladdr=1, sdl0=0x0) at ../../../netinet6/nd6_nbr.c:968 #16 0xc05c45dd in carp_send_na (sc=0xc69e9200) at ../../../netinet/ip_carp.c:1053 #17 0xc05c4e10 in carp_master_down_locked (sc=0xc69e9200) at ../../../netinet/ip_carp.c:1273 #18 0xc05c4d4b in carp_master_down (v=0xc69e9200) at ../../../netinet/ip_carp.c:1251 #19 0xc05370d9 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:271 If I allow the mutex to recurse, the panic goes away (of course) but I never see an advertisement being sent. CARP appears to work okay with IPv4. The cause of the panic is obvious, but I don't quite understand what carp_macmatch6 is for. Should it be supported in this code path? If so, I'll try to investigate further why advertisements aren't sent even after the mutex is allowed to recurse. I believe that the same issue exists in the 6-STABLE branch, but I can't be sure. It does not appear to work there with inet6, but that test was in a completely environment, so it might be a different issue. Is this issue known on -current?
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:54 UTC