From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yves-Alexis Perez Subject: Re: Regression for ip6-in-ip4 IPsec tunnel in 4.14.16 Date: Wed, 07 Feb 2018 20:46:26 +0100 Message-ID: <1518032786.4024.1.camel@debian.org> References: <1518021487.2100.2.camel@debian.org> <1518023139.2100.7.camel@debian.org> <1518024182.2136.3.camel@debian.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-xcjzKwrRtayp0DcLflyt" Cc: Mike Maloney , "David S. Miller" , Alexey Kuznetsov , Hideaki YOSHIFUJI , netdev , linux-kernel@vger.kernel.org, Eric Dumazet , Greg Kroah-Hartman , stable@vger.kernel.org, debian-kernel@lists.debian.org, Tobias Brunner To: Mike Maloney Return-path: In-Reply-To: Sender: stable-owner@vger.kernel.org List-Id: netdev.vger.kernel.org --=-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 >=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--