Date: Fri, 19 Feb 2021 17:24:44 -0800 From: Doug Hardie <bc979@lafn.org> To: "net@freebsd.org" <net@FreeBSD.org> Subject: Re: IPv6 Fragmentation Message-ID: <F483DD52-6D90-4CEC-9213-52D917BEEBEC@sermon-archive.info> In-Reply-To: <472A2B49-9BEC-4335-B6FB-AC4DAA0F0310@lurchi.franken.de> References: <CB0FB5AB-5A37-4C40-A103-3E0D97CEA6B9@sermon-archive.info> <472A2B49-9BEC-4335-B6FB-AC4DAA0F0310@lurchi.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 19 February 2021, at 01:48, Michael Tuexen = <michael.tuexen@lurchi.franken.de> wrote: >=20 >> On 19. Feb 2021, at 03:29, Doug Hardie <bc979@lafn.org> wrote: >>=20 >> I don't know if this is a feature or a bug. On FreeBSD 9, the = following ping worked: >>=20 >> ping6 -s 5000 -b 6000 fe80::213:72ff:fec3:180f%dc0 > I don't have a dc0 interface, but using re0 at one side and bge at the = other, I get > with FreeBSD CURRENT: > tuexen@cirrus:~ % ping6 -s 5000 -b 6000 fe80::2e09:4dff:fe00:c00%re0 > PING6(5048=3D40+8+5000 bytes) fe80::aaa1:59ff:fe0c:da92%re0 --> = fe80::2e09:4dff:fe00:c00%re0 > 5008 bytes from fe80::2e09:4dff:fe00:c00%re0, icmp_seq=3D0 hlim=3D255 = time=3D0.393 ms > 5008 bytes from fe80::2e09:4dff:fe00:c00%re0, icmp_seq=3D1 hlim=3D255 = time=3D0.419 ms > 5008 bytes from fe80::2e09:4dff:fe00:c00%re0, icmp_seq=3D2 hlim=3D255 = time=3D0.354 ms > 5008 bytes from fe80::2e09:4dff:fe00:c00%re0, icmp_seq=3D3 hlim=3D255 = time=3D0.446 ms > 5008 bytes from fe80::2e09:4dff:fe00:c00%re0, icmp_seq=3D4 hlim=3D255 = time=3D0.421 ms > 5008 bytes from fe80::2e09:4dff:fe00:c00%re0, icmp_seq=3D5 hlim=3D255 = time=3D0.372 ms > ^C > --- fe80::2e09:4dff:fe00:c00%re0 ping6 statistics --- > 6 packets transmitted, 6 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev =3D 0.354/0.401/0.446/0.031 ms >=20 > Best regards > Michael >>=20 >> It had to be stopped, but it returned the number of ping responses = received along with statistics. >>=20 >> With FreeBSD 12.2 and 13.0-BETA2, it returns 100% packet loss. = tcpdump shows that it properly fragments the data, sends it, the other = end receives it and sends back the ACKs. The ACKs are received, but = somehow ping doesn't find out that the packets were received. >>=20 >> Without the -s and -b arguments, it works and you get 100% packets = received. I brought up yet another system to see if I can isolate the problem. I = am using ping or ping6 with -s5000 -b6000 All of the systems have bge interfaces unfortunately, even though they = are completely different machine. ping from 12.1 to 13.0 works ping from 12.1 to 12.2 fails ping from 12.2 to 12.1 fails ping from 12.2 to 13.0 fails ping from 13.0 to 12.1 works ping from 13.0 to 12.2 fails =46rom this the problem appears to lie with 12.2. However, if I do the = same ping on each machine, but to its own link-local address, all 3 = systems work fine. I suspect the problem does not lie in the bge driver as the ACKs are = being received on all systems. 12.2 just seems to ignore them.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F483DD52-6D90-4CEC-9213-52D917BEEBEC>