Date: Mon, 20 Dec 2021 00:55:19 +0300 From: KOT MATPOCKuH <matpockuh@gmail.com> To: koobs@freebsd.org Cc: freebsd-stable List <freebsd-stable@freebsd.org>, Alan Somers <asomers@freebsd.org> Subject: Re: ping -6 ignores -e parameter Message-ID: <CALmdT0Vmu3_n_BVXkAr-izEmK_MDhuPezV3DXzNf8%2BE9ML8C7w@mail.gmail.com> In-Reply-To: <5140f4e1-df13-ebaa-341e-5274ead366ce@FreeBSD.org> References: <CALmdT0WvtUdteHKEw35tkgZyVzKW2ZT1LKmm1W62vQ_ev2QyPg@mail.gmail.com> <CAOtMX2jUey0qA8MTmRzjVmdQJp5-JOBEeLwGtoNvrucdvwcTWQ@mail.gmail.com> <22748b81-2ae8-babd-d07e-752ed15dce58@GMail.Com> <5140f4e1-df13-ebaa-341e-5274ead366ce@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Hello! I downloaded a daily snapshot VM from: https://download.freebsd.org/ftp/snapshots/VM-IMAGES/13.0-STABLE/amd64/20211216/FreeBSD-13.0-STABLE-amd64-20211216-defb7da9772-248589.raw.xz root@freebsd:~ # uname -a FreeBSD freebsd 13.0-STABLE FreeBSD 13.0-STABLE #0 stable/13-n248589-defb7da9772: Thu Dec 16 02:33:55 UTC 2021 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 It's 3 days later than 13th Dec. I checked on this VM and got the same behavior. Also I registered a bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260474 There You can find steps to reproduce this problem. Also can You assign this report to a proper responsible? сб, 18 дек. 2021 г. в 04:16, Kubilay Kocak <koobs@freebsd.org>: > On 16/12/2021 9:30 pm, KOT MATPOCKuH wrote: > > Hello, Alan! > > > > I'm sorry, I'm forget to add freebsd-stable@ to CC: list. > > > > Yes, I'm using FreeBSD 13: > > 13.0-STABLE > > > > Today I have a native IPv6 access and my inet6 routing table is: > > # netstat -rn6 | grep -v -e lo0 > > Routing tables > > > > Internet6: > > Destination Gateway Flags > > Netif Expire > > default fe80::206:29ff:fee9:32a9%lan0 UG > lan0 > > fd00:dead:beef:100::/64 link#5 U lan0 > > fe80::%lan0/64 link#5 U lan0 > > fe80::%bridge0/64 link#6 U bridge0 > > > > This means my default gateway is reachable via lan0. > > A node which link-local address fe80::2a0:98ff:fe1d:e270 is reachable > > via bridge0: > > # ping -c 1 fe80::2a0:98ff:fe1d:e270%bridge0 > > PING6(56=40+8+8 bytes) fe80::5a9c:fcff:fe10:ff9e%bridge0 --> > > fe80::2a0:98ff:fe1d:e270%bridge0 > > 16 bytes from fe80::2a0:98ff:fe1d:e270%bridge0, icmp_seq=0 hlim=64 > > time=0.804 ms > > > > But ping anyway sends packets via lan0. > > Also I tried to configure fd13:dead:beef::2 on bridge0, on corresponding > > node I configured fd13:dead:beef::1, and then run a command: > > ping -6 -e fd13:dead:beef::1 google.com > > > > In this way ping uses source IP address from bridge0 interface, but > > sends via lan0 and to next-hop fe80::206:29ff:fee9:32a9%lan0: > > # tcpdump -epni lan0 icmp6 > > 12:33:23.308763 8c:ec:4b:e9:28:23 > 00:06:29:e9:32:a9, ethertype IPv6 > > (0x86dd), length 70: fd13:dead:beef::2 > 2a00:1450:4010:c1e::8a: ICMP6, > > echo request, seq 52, length 16 > > > > I'm wrote a simple script to check this problem. I checked this script > > on image of VM from freebsd'site which FreeBSD-13. > > Please see attached file. > > > > On 15/12/2021 21:32, Alan Somers wrote: > >> On Wed, Dec 15, 2021 at 11:16 AM KOT MATPOCKuH <matpockuh@gmail.com> > >> wrote: > >>> > >>> Hello! > >>> > >>> In a man page for ping(8) and in it's help output I found option "-e": > >>> -e gateway > >>> Specifies to use gateway as the next hop to the > >>> destination. The > >>> gateway must be a neighbor of the sending node. > >>> > >>> I tried to use this argument, ping ignores this parameter and sends > >>> the packet via default gateway. > >>> For example I have a tun0 which has ipv6 default gw, and an > >>> established bridge0 which has available some LL addresses: > >>> Neighbor Linklayer Address Netif > >>> Expire S Flags > >>> fe80::2a0:98ff:fe1d:e270%bridge0 00:a0:98:1d:e2:70 bridge0 > >>> 23h56m34s S R > >>> > >>> I tried to run: > >>> ping -6 -e FE80::2A0:98FF:FE1D:E270%bridge0 google.com > >>> But the packet was sent via tun0 interface. > >>> > >>> What is wrong with it? > >>> > >>> -- > >>> MATPOCKuH > >> > >> What version of FreeBSD are you using? There was a major change to > >> ping's code in FreeBSD 13. Please show the output of > >> 'freebsd-version' and 'netstat -rn'. > >> -Alan > >> > > > > Potentially relevant issue issue who's stable/13 merge landed 2021-12-13: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258048 > > Is your uname -a version prior to or after this date? > > If after, can you test reverting this revision? > -- MATPOCKuH [-- Attachment #2 --] <div dir="ltr"><div>Hello!</div><div><br></div><div>I downloaded a daily snapshot VM from:<br></div><div><a href="https://download.freebsd.org/ftp/snapshots/VM-IMAGES/13.0-STABLE/amd64/20211216/FreeBSD-13.0-STABLE-amd64-20211216-defb7da9772-248589.raw.xz">https://download.freebsd.org/ftp/snapshots/VM-IMAGES/13.0-STABLE/amd64/20211216/FreeBSD-13.0-STABLE-amd64-20211216-defb7da9772-248589.raw.xz</a></div><div><br></div><div>root@freebsd:~ # uname -a<br>FreeBSD freebsd 13.0-STABLE FreeBSD 13.0-STABLE #0 stable/13-n248589-defb7da9772: Thu Dec 16 02:33:55 UTC 2021 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64</div><div><br></div><div>It's 3 days later than 13th Dec.<br></div><div>I checked on this VM and got the same behavior.</div><div>Also I registered a bug:</div><div><a href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260474">https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260474</a></div><div><br></div><div>There You can find steps to reproduce this problem.</div><div><br></div><div>Also can You assign this report to a proper responsible?<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">сб, 18 дек. 2021 г. в 04:16, Kubilay Kocak <<a href="mailto:koobs@freebsd.org">koobs@freebsd.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 16/12/2021 9:30 pm, KOT MATPOCKuH wrote:<br> > Hello, Alan!<br> > <br> > I'm sorry, I'm forget to add freebsd-stable@ to CC: list.<br> > <br> > Yes, I'm using FreeBSD 13:<br> > 13.0-STABLE<br> > <br> > Today I have a native IPv6 access and my inet6 routing table is:<br> > # netstat -rn6 | grep -v -e lo0<br> > Routing tables<br> > <br> > Internet6:<br> > Destination Gateway Flags <br> > Netif Expire<br> > default fe80::206:29ff:fee9:32a9%lan0 UG lan0<br> > fd00:dead:beef:100::/64 link#5 U lan0<br> > fe80::%lan0/64 link#5 U lan0<br> > fe80::%bridge0/64 link#6 U bridge0<br> > <br> > This means my default gateway is reachable via lan0.<br> > A node which link-local address fe80::2a0:98ff:fe1d:e270 is reachable <br> > via bridge0:<br> > # ping -c 1 fe80::2a0:98ff:fe1d:e270%bridge0<br> > PING6(56=40+8+8 bytes) fe80::5a9c:fcff:fe10:ff9e%bridge0 --> <br> > fe80::2a0:98ff:fe1d:e270%bridge0<br> > 16 bytes from fe80::2a0:98ff:fe1d:e270%bridge0, icmp_seq=0 hlim=64 <br> > time=0.804 ms<br> > <br> > But ping anyway sends packets via lan0.<br> > Also I tried to configure fd13:dead:beef::2 on bridge0, on corresponding <br> > node I configured fd13:dead:beef::1, and then run a command:<br> > ping -6 -e fd13:dead:beef::1 <a href="http://google.com" rel="noreferrer" target="_blank">google.com</a><br> > <br> > In this way ping uses source IP address from bridge0 interface, but <br> > sends via lan0 and to next-hop fe80::206:29ff:fee9:32a9%lan0:<br> > # tcpdump -epni lan0 icmp6<br> > 12:33:23.308763 8c:ec:4b:e9:28:23 > 00:06:29:e9:32:a9, ethertype IPv6 <br> > (0x86dd), length 70: fd13:dead:beef::2 > 2a00:1450:4010:c1e::8a: ICMP6, <br> > echo request, seq 52, length 16<br> > <br> > I'm wrote a simple script to check this problem. I checked this script <br> > on image of VM from freebsd'site which FreeBSD-13.<br> > Please see attached file.<br> > <br> > On 15/12/2021 21:32, Alan Somers wrote:<br> >> On Wed, Dec 15, 2021 at 11:16 AM KOT MATPOCKuH <<a href="mailto:matpockuh@gmail.com" target="_blank">matpockuh@gmail.com</a>> <br> >> wrote:<br> >>><br> >>> Hello!<br> >>><br> >>> In a man page for ping(8) and in it's help output I found option "-e":<br> >>> -e gateway<br> >>> Specifies to use gateway as the next hop to the <br> >>> destination. The<br> >>> gateway must be a neighbor of the sending node.<br> >>><br> >>> I tried to use this argument, ping ignores this parameter and sends <br> >>> the packet via default gateway.<br> >>> For example I have a tun0 which has ipv6 default gw, and an <br> >>> established bridge0 which has available some LL addresses:<br> >>> Neighbor Linklayer Address Netif <br> >>> Expire S Flags<br> >>> fe80::2a0:98ff:fe1d:e270%bridge0 00:a0:98:1d:e2:70 bridge0 <br> >>> 23h56m34s S R<br> >>><br> >>> I tried to run:<br> >>> ping -6 -e FE80::2A0:98FF:FE1D:E270%bridge0 <a href="http://google.com" rel="noreferrer" target="_blank">google.com</a><br> >>> But the packet was sent via tun0 interface.<br> >>><br> >>> What is wrong with it?<br> >>><br> >>> -- <br> >>> MATPOCKuH<br> >><br> >> What version of FreeBSD are you using? There was a major change to<br> >> ping's code in FreeBSD 13. Please show the output of<br> >> 'freebsd-version' and 'netstat -rn'.<br> >> -Alan<br> >><br> > <br> <br> Potentially relevant issue issue who's stable/13 merge landed 2021-12-13:<br> <br> <a href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258048" rel="noreferrer" target="_blank">https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258048</a><br>; <br> Is your uname -a version prior to or after this date?<br> <br> If after, can you test reverting this revision?<br> </blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">MATPOCKuH</div>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALmdT0Vmu3_n_BVXkAr-izEmK_MDhuPezV3DXzNf8%2BE9ML8C7w>