Date: Tue, 2 Nov 2021 16:06:02 +0300 From: "Andrey V. Elsukov" <bu7cher@yandex.ru> To: Peter <pmc@citylink.dinoex.sub.org> Cc: freebsd-stable@freebsd.org, "Bjoern A. Zeeb" <bz@FreeBSD.org>, "Alexander V. Chernikov" <melifaro@freebsd.org> Subject: Re: IPv6 inflight fragmentation Message-ID: <4f63aa64-6ff0-7eb0-6043-70b0205fa8f2@yandex.ru> In-Reply-To: <YYBUmpf%2B%2BLXh9jR7@gate.intra.daemon.contact> References: <YX3%2BWa0xSKeZWGLz@gate.intra.daemon.contact> <4053ee14-de6a-7f20-1d15-bb6ddb3c4d66@yandex.ru> <YYBUmpf%2B%2BLXh9jR7@gate.intra.daemon.contact>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--fAHkCGTItiJqywcASEp5rf1CCAqzYWfei
Content-Type: multipart/mixed; boundary="ytN7Xc48yOHN0CYl6v6Qdd3tSQvRdTfMx";
protected-headers="v1"
From: "Andrey V. Elsukov" <bu7cher@yandex.ru>
To: Peter <pmc@citylink.dinoex.sub.org>
Cc: freebsd-stable@freebsd.org, "Bjoern A. Zeeb" <bz@FreeBSD.org>,
"Alexander V. Chernikov" <melifaro@freebsd.org>
Message-ID: <4f63aa64-6ff0-7eb0-6043-70b0205fa8f2@yandex.ru>
Subject: Re: IPv6 inflight fragmentation
References: <YX3+Wa0xSKeZWGLz@gate.intra.daemon.contact>
<4053ee14-de6a-7f20-1d15-bb6ddb3c4d66@yandex.ru>
<YYBUmpf++LXh9jR7@gate.intra.daemon.contact>
In-Reply-To: <YYBUmpf++LXh9jR7@gate.intra.daemon.contact>
--ytN7Xc48yOHN0CYl6v6Qdd3tSQvRdTfMx
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
01.11.2021 23:56, Peter =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> ! divert rule does implicit IP fragments reassembling before passing a
> ! packet to application. I don't think dummynet is affected by this.
>=20
> No, we're not going to an application, we are routing to the
> Internet. And the uplink iface (tun0) has mtu=3D1492. And we have a rul=
e
> in ipfw, like:
>=20
>> queue 21 proto all <whatever> xmit tun0 out
>=20
> And we have sysctl net.inet.ip.fw.one_pass=3D0
>=20
> So, at the time when we go thru the queue, we do not yet know the
> actual interface to use for xmit (because there might still be a
> "forward" rule following), so we do not yet know the mtu.
>=20
> Only when we finally give the packet out for sending, *after* passing
> the queue, then we will recognize our actual mtu. And then the
> difference happens:
>=20
> * if we did *not* go through the queue, the packet is (probably)
> dropped and an ICMPv6 type 2 ("too big") is sent back to the
> originator. This is how I understand that it should work, and
> that works.
Hi,
without divert/dummynet rules packets are handled trough usual
forwarding path. I.e. ip6_tryforward() handles MTU case and sends
ICMP6_PACKET_TOO_BIG message.
> * if we *did* go through the queue, the packet is split into
> fragments although it is IPv6. And that does not work; such packet
> does not get answered by Youtube, and playback hangs. From a quick
> glance the fragments do look technically correct - and I have no
> idea why YT would receive a fullsized packet from the player,
> anyway (and I won't analyze their stuff).
And there it seems we have the problem. When you use dummynet rule with
"out xmit" opcode, it is handled on PFIL_OUT|PFIL_FWD pass. And as the
result, dummynet consumes a packet and sends it to ip6_output() with
IPV6_FORWARDING flag. Currently this flag does make some sense only for
multicast routing. And there is the problem - the router that uses
dummynet rule for forwarded packet can do IP fragmentation, that it must
not do.
Alexander and Bjoern, can you take a look at this?
I made a quick patch that does check for PFIL_FWD and IPV6_FORWARDING
flags. So, dummynet now knows that we are forwarding and sets
IPV6_FORWARDING only in that case. Then ip6_output() does set dontfrag
variable when we have IPV6_FORWARDING. And in the end, when we got
EMSGSIZE error with IPV6_FORWARDING flag, we send ICMP6_PACKET_TOO_BIG
error message instead of quiet dropping.
https://people.freebsd.org/~ae/ip6_dont_frag.diff
The patch doesn't touch divert code. I think diverted packet can be
assumed as locally generated, so it is ok to fragment it.
> The behaviour is the same if there is either a "queue" action or
> a "divert" action or both.
> With "divert" we know that the mbuf flags are lost - with dummynet
> I did not yet look into the code. I had a hard time finding the cause
> in bulky video data, and then I simply reduced the mtu one hop earlier
> within my intranet, to workaround the issue for now.
As a workaround usually it is enough to use tcp-setmss opcode.
--=20
WBR, Andrey V. Elsukov
--ytN7Xc48yOHN0CYl6v6Qdd3tSQvRdTfMx--
--fAHkCGTItiJqywcASEp5rf1CCAqzYWfei
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"
-----BEGIN PGP SIGNATURE-----
wsB5BAABCAAjFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAmGBN7sFAwAAAAAACgkQAcXqBBDIoXp8
tgf/dp50XdZAdcWQgPwB8KQuVZ+1Rikmevt/BAkyBWcwFjESe+able7KQjzpk641Hc0WmqDvKFA1
OyOdwARKwER6o7d7EMYhJGjT/2IRS+cubgPNettnpHxYoewfYQup+Fb1w9wAtfYTobFOK9s/lFpn
RE+gzkelwNZuC4syXpcKXcjNVsd2FXWciA/vYR/v73rZNpPGrdj/5BGU8lEdjyOt5kLEHvq9o00T
ymJ9KZdnj2VPe21+K/kXD5wwWIxfWILTN0wm0E5olfFY/ZYq/N2DvSnEUqzpK3wFuJ+1TnYWHvG2
0gdQLvQUbN5yp2OW+8+VAF0PtWSI/H5+Il1q7dvUgw==
=sfW/
-----END PGP SIGNATURE-----
--fAHkCGTItiJqywcASEp5rf1CCAqzYWfei--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4f63aa64-6ff0-7eb0-6043-70b0205fa8f2>