netdev - Re: [PATCH net] gre: Fix MTU sizing check for gretap tunnels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51DF4A3E.8070102@gmail.com>
Date:	Thu, 11 Jul 2013 17:13:50 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Jesse Gross <jesse@...ira.com>
CC:	Pravin Shelar <pshelar@...ira.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH net] gre: Fix MTU sizing check for gretap tunnels

On 07/11/2013 04:36 PM, Jesse Gross wrote:
> On Thu, Jul 11, 2013 at 4:19 PM, Pravin Shelar <pshelar@...ira.com> wrote:
>> On Thu, Jul 11, 2013 at 3:45 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
>>> On Thu, 2013-07-11 at 15:24 -0700, Pravin Shelar wrote:
>>>> On Thu, Jul 11, 2013 at 1:12 PM, Alexander Duyck
>>>> <alexander.h.duyck@...el.com> wrote:
>>>>> This change fixes an MTU sizing issue seen with gretap tunnels when non-gso
>>>>> packets are sent from the interface.
>>>>>
>>>>> In my case I was able to reproduce the issue by simply sending a ping of
>>>>> 1421 bytes with the gretap interface created on a device with a standard
>>>>> 1500 mtu.
>>>>>
>>>>> This fix is based on the fact that the tunnel mtu is already adjusted by
>>>>> dev->hard_header_len so it would make sense that any packets being compared
>>>>> against that mtu should also be adjusted by hard_header_len and the tunnel
>>>>> header instead of just the tunnel header.
>>>>>
>>>> we can simplify code by not doing dev->hard_header_len adjustment to tunnel-mtu.
>>>>
>>>> And right thing would be adjusting tunnel-mtu according to rt->dst.dev
>>>> header-len so that we get mtu for out going path.
>>> What's the mtu value we want to put in the ICMP message ?
>>>
>>>
>> I think it should be max payload that tunnel-device can take for that
>> route. Something like (route_mtu - (tunnel_header_len + iph_len +
>> route_dev->header_len))
>>
>> gre is been using dev->hard_header_len rather than
>> rt_dev->hard_header_len for long time which does not look right.
> I think that it is trying to use the tunnel device's header length to
> get the payload length. The MTU of the output device should already
> take into account its header length. I agree that the code is hard to
> read right now though

That is what I assume as well.  The only issue was the fact that after
the recent changes the calculation was off as it was including the
Ethernet header size when calculating the network packet size in the
case of gretap.  Prior to recent changes this code just pulled the
network packet size out of the network header when comparing it to the MTU.

Thanks,

Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html