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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAEP_g=9oLO-LO8UD01VdGESRJrE2yhAPFpuoO_Qrwh=G7FvdhQ@mail.gmail.com>
Date:	Thu, 11 Jul 2013 16:36:09 -0700
From:	Jesse Gross <jesse@...ira.com>
To:	Pravin Shelar <pshelar@...ira.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Alexander Duyck <alexander.h.duyck@...el.com>,
	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH net] gre: Fix MTU sizing check for gretap tunnels

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.
--
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