All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: Steffen Klassert <steffen.klassert@secunet.com>,
	Alexander Duyck <alexander.duyck@gmail.com>
Cc: David Miller <davem@davemloft.net>, NetDev <netdev@vger.kernel.org>
Subject: Re: Looking for a lost patch
Date: Mon, 18 May 2015 09:02:22 -0700	[thread overview]
Message-ID: <555A0D0E.5040102@redhat.com> (raw)
In-Reply-To: <20150518073809.GD8928@secunet.com>

On 05/18/2015 12:38 AM, Steffen Klassert wrote:
> On Wed, May 13, 2015 at 10:47:11AM -0700, Alexander Duyck wrote:
>> So I am in the process of trying to do some work on VTI6 and in the
>> process of doing so I am trying to setup an IPv4 VTI tunnel and I
>> have come across what appears to be a lost patch.
>>
>> So in commit a32452366b72 ("vti4: Don't count header length twice.")
>> the following change was made:
>>
>> diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
>> index 687ddef..cd62596 100644
>> --- a/net/ipv4/ip_vti.c
>> +++ b/net/ipv4/ip_vti.c
>> @@ -349,7 +349,6 @@ static int vti_tunnel_init(struct net_device *dev)
>>   	memcpy(dev->broadcast, &iph->daddr, 4);
>>
>>   	dev->type		= ARPHRD_TUNNEL;
>> -	dev->hard_header_len	= LL_MAX_HEADER + sizeof(struct iphdr);
>>   	dev->mtu		= ETH_DATA_LEN;
>>   	dev->flags		= IFF_NOARP;
>>   	dev->iflink		= 0;
>>
>> However in commit f895f0cfbb77 ("Merge branch 'master' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec") the
>> change appears to have been undone as a result of a merge commit.
>>
>> I'm just wondering which is correct.  Should the hard_header_len be
>> set or unset in vti_tunnel_init?  I ask because I have two kernels
>> and one has the patch and one does not and I am seeing an MTU of
>> 1332 for a VTI tunnel without, and 1480 for a VTI tunnel with.
> A MTU of 1332 is definitively wrong. Actually I think a vti
> tunnel can have a MTU of 1500 because xfrm cares to calculate
> a PMTU based on the used states. The MTU of 1480 is because
> the generic ip_tunnel_bind_dev() assumes that an ip tunnel
> has always the overhead of an additional ip header. On IPsec
> this header is included in the PMTU calculation.

So if I understand correctly then is 1480 the correct MTU or should I be 
looking for some other value?

My initial though was to try and find the maximum overhead that can be 
generated for an IPv4/IPSec tunnel.  However it seems like there isn't 
any solid documentation anywhere on what the upper limit is. I notice a 
number of references use either 1400 or 1412, however these tunnels 
appear to be using either an arbitrary value or a value that seems to 
also account for PPP and GRE overhead.

- Alex

  reply	other threads:[~2015-05-18 16:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13 17:47 Looking for a lost patch Alexander Duyck
2015-05-18  7:38 ` Steffen Klassert
2015-05-18 16:02   ` Alexander Duyck [this message]
2015-05-19  7:57     ` Steffen Klassert
2015-05-19 18:32       ` Alexander Duyck
2015-05-20  6:32         ` Steffen Klassert
2015-05-21  2:06           ` Alexander Duyck
2015-05-21 21:25           ` David Miller
2015-05-27  8:35             ` Steffen Klassert
2015-05-27 15:46               ` David Miller
2015-05-28  5:51                 ` Steffen Klassert

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=555A0D0E.5040102@redhat.com \
    --to=alexander.h.duyck@redhat.com \
    --cc=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.