Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <1518032786.4024.1.camel@debian.org>
Subject: Re: Regression for ip6-in-ip4 IPsec tunnel in 4.14.16
From:   Yves-Alexis Perez <corsac@debian.org>
To:     Mike Maloney <maloneykernel@gmail.com>
Cc:     Mike Maloney <maloney@google.com>,
        "David S. Miller" <davem@davemloft.net>,
        Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
        netdev <netdev@vger.kernel.org>, linux-kernel@vger.kernel.org,
        Eric Dumazet <edumazet@google.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        stable@vger.kernel.org, debian-kernel@lists.debian.org,
        Tobias Brunner <tobias@strongswan.org>
Date:   Wed, 07 Feb 2018 20:46:26 +0100
In-Reply-To: <CAJegeYkqg97ZyiJRe9ZZAk_C_KX_NrcmuK9SRrEbLzHMXfdv1Q@mail.gmail.com>
References: <1518021487.2100.2.camel@debian.org>
         <1518023139.2100.7.camel@debian.org> <1518024182.2136.3.camel@debian.org>
         <CAJegeYkqg97ZyiJRe9ZZAk_C_KX_NrcmuK9SRrEbLzHMXfdv1Q@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256";
        protocol="application/pgp-signature"; boundary="=-xcjzKwrRtayp0DcLflyt"
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--=-xcjzKwrRtayp0DcLflyt
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2018-02-07 at 13:50 -0500, Mike Maloney wrote:
> On Wed, Feb 7, 2018 at 12:23 PM, Yves-Alexis Perez <corsac@debian.org>
>=20
> Hi Yves-Alexis -
>=20
> I apologize for the problem.  It seems to me that tunneling with an
> outer MTU that causes the inner MTU to be smaller than the min, is
> potentially problematic in other ways as well.

Maybe. I tried with removing the MTU setting, and I get (on ping again)

f=C3=A9vr. 07 20:44:01 scapa kernel: mtu: 1266

which means I would get -EINVAL on standards kernels, which is not really g=
ood
either.

> But also it could seem unfortunate that the code with my fix does not
> look at actual packet size, but instead only looks at the MTU and then
> fails, even if no packet was going to be so large.  The intention of
> my patch was to prevent a negative number while calculating the
> maxfraglen in  __ip6_append_data().  An alternative fix maybe to
> instead return an error only if the mtu is less than or equal to the
> fragheaderlen.   Something like:
>=20
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 3763dc01e374..5d912a289b95 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -1214,8 +1214,6 @@ static int ip6_setup_cork(struct sock *sk,
> struct inet_cork_full *cork,
>                 if (np->frag_size)
>                         mtu =3D np->frag_size;
>         }
> -       if (mtu < IPV6_MIN_MTU)
> -               return -EINVAL;
>         cork->base.fragsize =3D mtu;
>         if (dst_allfrag(rt->dst.path))
>                 cork->base.flags |=3D IPCORK_ALLFRAG;
> @@ -1264,6 +1262,8 @@ static int __ip6_append_data(struct sock *sk,
>=20
>         fragheaderlen =3D sizeof(struct ipv6hdr) + rt->rt6i_nfheader_len =
+
>                         (opt ? opt->opt_nflen : 0);
> +       if (mtu < fragheaderlen + 8)
> +               return -EINVAL;
>         maxfraglen =3D ((mtu - fragheaderlen) & ~7) + fragheaderlen -
>                      sizeof(struct frag_hdr);
>                         (opt ? opt->opt_nflen : 0);
>=20
> But then we also have to convince ourselves that maxfraglen can never
> be <=3D 0.  I'd have to think about that.
>=20
> I am not sure if others have thoughts on supporting MTUs configured
> below the min in the spec.
>=20
Here, the MTU is not below, so I'm not sure what happens.

Regards,
--=20
Yves-Alexis
--=-xcjzKwrRtayp0DcLflyt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlp7V5IACgkQ3rYcyPpX
RFvW8Af+OCN9KuYMrqEiMKNEa3mpucZMOgWDQirN/pH+NmZqbr2Dfv1GaBoKbuZT
inIAoati6lE43Kg87J8nii9mwTFQzS9F85KKSWoRZsVKAetXYNOpah9tjVeAG4yU
JSrKsSqwyfPb3nUMUHnUanZDBweBvltMu7aT6BscRg38eJ4pUE7xwMk2Zt3HFHMW
IcPX6buiOW1rdfP27l9CGusFMdiwSizXYxGWQKw7XFWm0gawOrw98kAowiHK6gcd
4Y3jpZA6QWrcMHHDQa1Y4BfE8+luLuEDegL8mCh15QlNcs9BIm+ZtZozAVE2JEPR
UAG9yRcNrKSMxEGZuH9ce5VTEeQm3w==
=Bj06
-----END PGP SIGNATURE-----

--=-xcjzKwrRtayp0DcLflyt--