Date: Thu, 14 Jan 2021 11:34:29 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: "Andrey V. Elsukov" <bu7cher@yandex.ru>, Lutz Donnerhacke <lutz@donnerhacke.de>, freebsd-net@freebsd.org, Hans Petter Selasky <hps@selasky.org> Subject: Re: FreeBSD does not reply to IPv6 Neighbor Solicitations Message-ID: <20210114193429.GT31099@funkthat.com> In-Reply-To: <20210114015917.GR31099@funkthat.com> References: <E9644A2A-6C5F-48C9-AD2D-13BC7FB2E534@gromit.dlib.vt.edu> <20210105031528.GA91534@admin.sibptus.ru> <00a101d6e33b$96edf0c0$c4c9d240$@donnerhacke.de> <20210105104650.GA7688@admin.sibptus.ru> <00b601d6e35a$115a4a20$340ede60$@donnerhacke.de> <20210112022525.GN31099@funkthat.com> <95be49e2-56cc-cf3f-3515-8f13f14ddbad@yandex.ru> <20210112213707.GP31099@funkthat.com> <065eaff7-35bd-0cd3-f68f-849be2178574@yandex.ru> <20210114015917.GR31099@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney wrote this message on Wed, Jan 13, 2021 at 17:59 -0800: > Andrey V. Elsukov wrote this message on Wed, Jan 13, 2021 at 11:42 +0300: > > On 13.01.2021 00:37, John-Mark Gurney wrote: > > >> when this will happen again, it would be nice to make sure that NS > > >> packets hit the IP stack. E.g. with attached dtrace script. > > > > > > Ok, I ran the dtrace script when I reproduced the problem, and it did > > > not produce any output. > > > > > > These are effectively what the script does: > > > 9) configure inet6 addresses on ure and bge (duplicating the addresses > > > already configured) > > > > Does it mean that you just reconfigure address without removing it? It > > looks like the problem, that was discussed here > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233535 > > Yeah, I guess it is the same... > > > > bge0: > > > inet6 fe80::12e7:c6ff:fexx:xxxx%bge0 scopeid 0x2 > > > mldv2 flags=2<USEALLOW> rv 2 qi 125 qri 10 uri 3 > > > group ff01::1%bge0 scopeid 0x2 mode exclude > > > mcast-macaddr 33:33:00:00:00:01 > > > group ff02::1%bge0 scopeid 0x2 mode exclude > > > mcast-macaddr 33:33:00:00:00:01 > > > group ff02::1:ffxx:xxxx%bge0 scopeid 0x2 mode exclude > > > mcast-macaddr 33:33:ff:xx:xx:xx > > > > > > so, I made things works, and ran ifmcstat again, and this time it has > > > an additional group in the output: > > > [...] > > > bge0: > > > inet6 fe80::12e7:c6ff:fexx:xxxx%bge0 scopeid 0x2 > > > mldv2 flags=2<USEALLOW> rv 2 qi 125 qri 10 uri 3 > > > group ff02::1:ff00:c43c%bge0 scopeid 0x2 mode exclude > > > mcast-macaddr 33:33:ff:00:c4:3c > > > group ff01::1%bge0 scopeid 0x2 mode exclude > > > mcast-macaddr 33:33:00:00:00:01 > > > group ff02::1%bge0 scopeid 0x2 mode exclude > > > mcast-macaddr 33:33:00:00:00:01 > > > group ff02::1:ffxx:xxxx%bge0 scopeid 0x2 mode exclude > > > mcast-macaddr 33:33:ff:xx:xx:xx > > > > > > and the tcpdump output: > > > 21:10:53.938655 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 > > > 21:10:55.001428 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 > > > > Since ff02::1:ff00:c43c%bge0 is not configured in first case, IP stack > > just ignores NS messages and they don't hit ND6 code. > > > > In the PR 233535 the problem was reproducible with MLDv1, so if you > > disable MLDv2 will it work (to reduce possible scope of problematic code)? > > > > net.inet6.mld.v2enable=0 > > I just tested this, and it does not fix the problem for me. > > Do I need to reboot or something? If I set it to 0, the bug > still appears, and also the ifmcstat has the line: > mldv2 flags=2<USEALLOW> rv 2 qi 125 qri 10 uri 3 > > is there something else that needs to be done to disable mldv2? I was able to reproduce using epair on a single system. It did take a few runs of the test before it failed, but it was able to fail. So, to reproduce, on a -current system (mine is main-c255640-gc38e59ce1b0), do: ifconfig epair0 create sh ipv6.failure.sh init epair0a epair0b sh ipv6.failure.sh run epair0a epair0b sh ipv6.failure.sh run epair0a epair0b sh ipv6.failure.sh run epair0a epair0b sh ipv6.failure.sh run epair0a epair0b In my case, it failed on the fourth try, but it does appear to be inconsistent, as a fifth run worked, but then the sixth run failed again, and additional runs worked... If you want to see the live tcpdump, you can run the following commands in a coupld different windows: jexec testjail tcpdump -n -p -i epair0a and: jexec checkjail tcpdump -n -p -i epair0b uname -a: FreeBSD test 13.0-CURRENT FreeBSD 13.0-CURRENT #7 main-c255640-gc38e59ce1b0: Sat Jan 9 01:55:25 UTC 2021 root@test:/usr/obj/usr/src.git/amd64.amd64/sys/GENERIC amd64 and the cpu: CPU: AMD PRO A10-8770E R7, 10 COMPUTE CORES 4C+6G (2794.80-MHz K8-class CPU) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210114193429.GT31099>