netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>
Subject: Re: Regression for ip6-in-ip4 IPsec tunnel in 4.14.16
Date: Wed, 07 Feb 2018 20:46:26 +0100	[thread overview]
Message-ID: <1518032786.4024.1.camel@debian.org> (raw)
In-Reply-To: <CAJegeYkqg97ZyiJRe9ZZAk_C_KX_NrcmuK9SRrEbLzHMXfdv1Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2372 bytes --]

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>
> 
> Hi Yves-Alexis -
> 
> 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évr. 07 20:44:01 scapa kernel: mtu: 1266

which means I would get -EINVAL on standards kernels, which is not really good
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:
> 
> 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 = np->frag_size;
>         }
> -       if (mtu < IPV6_MIN_MTU)
> -               return -EINVAL;
>         cork->base.fragsize = mtu;
>         if (dst_allfrag(rt->dst.path))
>                 cork->base.flags |= IPCORK_ALLFRAG;
> @@ -1264,6 +1262,8 @@ static int __ip6_append_data(struct sock *sk,
> 
>         fragheaderlen = sizeof(struct ipv6hdr) + rt->rt6i_nfheader_len +
>                         (opt ? opt->opt_nflen : 0);
> +       if (mtu < fragheaderlen + 8)
> +               return -EINVAL;
>         maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen -
>                      sizeof(struct frag_hdr);
>                         (opt ? opt->opt_nflen : 0);
> 
> But then we also have to convince ourselves that maxfraglen can never
> be <= 0.  I'd have to think about that.
> 
> I am not sure if others have thoughts on supporting MTUs configured
> below the min in the spec.
> 
Here, the MTU is not below, so I'm not sure what happens.

Regards,
-- 
Yves-Alexis

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2018-02-07 19:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-07 16:38 Regression for ip6-in-ip4 IPsec tunnel in 4.14.16 Yves-Alexis Perez
2018-02-07 17:05 ` Yves-Alexis Perez
2018-02-07 17:23   ` Yves-Alexis Perez
2018-02-07 18:50     ` Mike Maloney
2018-02-07 19:46       ` Yves-Alexis Perez [this message]
2018-02-08 12:40         ` Yves-Alexis Perez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1518032786.4024.1.camel@debian.org \
    --to=corsac@debian.org \
    --cc=davem@davemloft.net \
    --cc=debian-kernel@lists.debian.org \
    --cc=edumazet@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maloney@google.com \
    --cc=maloneykernel@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tobias@strongswan.org \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).