From owner-freebsd-stable@freebsd.org Tue Sep 5 15:25:19 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE167E0E78D for ; Tue, 5 Sep 2017 15:25:19 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from roadkill.tharned.org (gcrivers-1-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:107f::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 759EA82E11 for ; Tue, 5 Sep 2017 15:25:19 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from flake.tharned.org ([IPv6:2001:470:1f11:107f:fcb7:e619:e59d:bac1]) (authenticated bits=0) by roadkill.tharned.org (8.15.2/8.15.2) with ESMTPSA id v85FPCOn093655 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Sep 2017 10:25:17 -0500 (CDT) (envelope-from gcr+freebsd-stable@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2017; t=1504625117; bh=K8D/5QwFj+OcKlee7R7rHyUZ2SYXwPqBpDwQgR5ImKI=; l=5972; h=From:To:Subject:Date:In-Reply-To:References; b=FeQpdJ3+k6qbV6PzkV3HzApnO6v8wWGLdwlJ2dQ8k7VHfuJX7LM5C5PKNISOb2S+V X8AFeniZMrVcNXfGfAi+TT4zIzE1c/v+1hiUESuXjBrW0k7iQit123zOyvS6e/7SB9 KwzATsbDb9hzkQFwl5ToSBNgMfnfTpA8KAcH/budOb0ew9c3FwJp+q+IVSsV5+9twF R0YVdGNaBvbdlRCnrUg9QJ1UkXJ9XjWiiDvMumKNFsoioolXx2h85VofMHo9BgdnBO HC52HOqJ0WANKz0bOucx8JW2AHB2UX5CFaKKgTCdpMz1dTAHSBV+IqP0stbM63if7B w93LjQ9o5cY7g== X-Authentication-Warning: roadkill.tharned.org: Host [IPv6:2001:470:1f11:107f:fcb7:e619:e59d:bac1] claimed to be flake.tharned.org From: Greg Rivers To: "Andrey V. Elsukov" , freebsd-stable@freebsd.org Subject: Re: SLAAC not working Date: Tue, 05 Sep 2017 10:25:12 -0500 Message-ID: <1762879.zBQMMkUt4K@flake.tharned.org> User-Agent: KMail/4.14.10 (FreeBSD/11.1-RELEASE-p1; KDE/4.14.30; amd64; ; ) In-Reply-To: <37bf1f27-0cdd-b5a9-7345-d16eb228c4cb@yandex.ru> References: <1646645.UkMcyRZBVl@flake.tharned.org> <16545541.lkKC6IFVDn@flake.tharned.org> <37bf1f27-0cdd-b5a9-7345-d16eb228c4cb@yandex.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (roadkill.tharned.org [IPv6:2001:470:1f10:107f:0:0:0:2]); Tue, 05 Sep 2017 10:25:17 -0500 (CDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 15:25:19 -0000 On Tuesday, September 05, 2017 13:51:32 Andrey V. Elsukov wrote: > You can try to use dtrace to detect that RA is received by IPv6 stack. > # kldload dtraceall > # dtrace -n 'fbt::nd6_ra_input:entry {m = (struct mbuf *)arg0; ip6 = > (struct ip6_hdr *)m->m_data; printf("RA from %s received on %s", > inet_ntoa6(&ip6->ip6_src), stringof(m->m_pkthdr.rcvif->if_xname));}' > > It should produce the output like this: > dtrace: description 'fbt::nd6_ra_input:entry ' matched 1 probe > CPU ID FUNCTION:NAME > 2 37912 nd6_ra_input:entry RA from > fe80:1::92e2:baff:fe6a:c7c received on ix0 > 2 37912 nd6_ra_input:entry RA from > fe80:1::92e2:baff:fe6a:c7c received on ix0 > Thank you Andrey! I started both dtrace and tcpdump, and then ran rtsol; here's the result: # rtsol -dD lagg0 checking if lagg0 is ready... lagg0 is ready set timer for lagg0 to 0s New timer is 0s timer expiration on lagg0, state = 1 send RS on lagg0, whose state is 2 set timer for lagg0 to 4s New timer is 4s timer expiration on lagg0, state = 2 send RS on lagg0, whose state is 2 set timer for lagg0 to 4s New timer is 4s timer expiration on lagg0, state = 2 send RS on lagg0, whose state is 2 set timer for lagg0 to 1s New timer is 1s timer expiration on lagg0, state = 2 No answer after sending 3 RSs stop timer for lagg0 there is no timer # tcpdump -tttt -i lagg0 ip6 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lagg0, link-type EN10MB (Ethernet), capture size 262144 bytes 2017-09-05 09:30:24.195501 IP6 fe80::ae16:2dff:fe1e:b880 > ff02::2: ICMP6, router solicitation, length 16 2017-09-05 09:30:24.195573 IP6 fe80::ae16:2dff:fe1e:b880 > ff02::2: ICMP6, router solicitation, length 16 2017-09-05 09:30:28.199198 IP6 fe80::ae16:2dff:fe1e:b880 > ff02::2: ICMP6, router solicitation, length 16 2017-09-05 09:30:28.199395 IP6 fe80::ae16:2dff:fe1e:b880 > ff02::2: ICMP6, router solicitation, length 16 2017-09-05 09:30:28.199724 IP6 fe80:XXXX:XXXX:4013:23::2 > fe80::ae16:2dff:fe1e:b880: ICMP6, router advertisement, length 64 2017-09-05 09:30:28.199729 IP6 fe80:XXXX:XXXX:4013:23::3 > fe80::ae16:2dff:fe1e:b880: ICMP6, router advertisement, length 64 2017-09-05 09:30:29.196133 IP6 fe80:XXXX:XXXX:4013:23::2 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32 2017-09-05 09:30:29.196369 IP6 fe80:XXXX:XXXX:4013:23::3 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32 2017-09-05 09:30:30.196234 IP6 fe80:XXXX:XXXX:4013:23::2 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32 2017-09-05 09:30:30.196649 IP6 fe80:XXXX:XXXX:4013:23::3 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32 2017-09-05 09:30:31.196341 IP6 fe80:XXXX:XXXX:4013:23::2 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32 2017-09-05 09:30:31.196915 IP6 fe80:XXXX:XXXX:4013:23::3 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32 2017-09-05 09:30:32.199683 IP6 fe80::ae16:2dff:fe1e:b880 > ff02::2: ICMP6, router solicitation, length 16 2017-09-05 09:30:32.199746 IP6 fe80::ae16:2dff:fe1e:b880 > ff02::2: ICMP6, router solicitation, length 16 2017-09-05 09:30:32.200289 IP6 fe80:XXXX:XXXX:4013:23::3 > fe80::ae16:2dff:fe1e:b880: ICMP6, router advertisement, length 64 2017-09-05 09:30:32.200597 IP6 fe80:XXXX:XXXX:4013:23::2 > fe80::ae16:2dff:fe1e:b880: ICMP6, router advertisement, length 64 2017-09-05 09:30:37.200331 IP6 fe80:XXXX:XXXX:4013:23::2 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32 2017-09-05 09:30:37.212444 IP6 fe80:XXXX:XXXX:4013:23::3 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32 2017-09-05 09:30:38.200407 IP6 fe80:XXXX:XXXX:4013:23::2 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32 2017-09-05 09:30:38.212714 IP6 fe80:XXXX:XXXX:4013:23::3 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32 2017-09-05 09:30:39.200517 IP6 fe80:XXXX:XXXX:4013:23::2 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32 2017-09-05 09:30:39.213490 IP6 fe80:XXXX:XXXX:4013:23::3 > fe80::ae16:2dff:fe1e:b880: ICMP6, neighbor solicitation, who has fe80::ae16:2dff:fe1e:b880, length 32 ^C 22 packets captured 38215 packets received by filter 0 packets dropped by kernel # dtrace -n 'fbt::nd6_ra_input:entry {m = (struct mbuf *)arg0; ip6 = (struct ip6_hdr *)m->m_data; printf("RA from %s received on %s", inet_ntoa6(&ip6->ip6_src), stringof(m->m_pkthdr.rcvif->if_xname));}' dtrace: description 'fbt::nd6_ra_input:entry ' matched 1 probe ^C dtrace saw nothing, yet tcpdump recorded what one would expect. Apparently the inbound RAs and NSs are not making it through to the IPv6 stack. At this point I suspect a bug in the Emulex oce(4) driver, or a bad interaction between oce(4) and lagg(4). I have not seen this issue on hosts with lagg and other NICs. As soon as I can, I'm going to eliminate lagg and repeat the experiment while running on just one oce interface. I'll report back with results. > > $ ping6 fe80:XXXX:XXXX:4013:23::2%lagg0 > > ping6: UDP connect: Network is unreachable > > Hmm. Can you show the second word of address in this example? > Is it not zero? I.e. fe80:XXXX: is correct or you missed '::' part? > Correct, neither of the XXXX parts are zero; the :: part is at the end of the address: ...::2%lagg0. Sorry for the obfuscation, but policy at $WORK about company information on public lists is very strict. -- Greg Rivers