linux-kernel - Re: Inconsistency in packet drop due to MTU (eth vs veth)

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] [day] [month] [year] [list]

Date:   Fri, 3 Feb 2017 23:42:32 +0900
From:   Toshiaki Makita <toshiaki.makita1@...il.com>
To:     Fredrik Markstrom <fredrik.markstrom@...il.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        netdev <netdev@...r.kernel.org>, Evan Jones <ej@...njones.ca>,
        "David S. Miller" <davem@...emloft.net>,
        Cong Wang <cwang@...pensource.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Vijay Pandurangan <vijayp@...ayp.ca>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        ebiederm <ebiederm@...stanetworks.com>
Subject: Re: Inconsistency in packet drop due to MTU (eth vs veth)

On 17/02/03 (金) 17:07, Fredrik Markstrom wrote:
>  ---- On Tue, 31 Jan 2017 17:27:09 +0100 Eric Dumazet <eric.dumazet@...il.com> wrote ----
>  > On Tue, 2017-01-31 at 14:32 +0100, Fredrik Markstrom wrote:
>  > >  ---- On Thu, 19 Jan 2017 19:53:47 +0100 Eric Dumazet <eric.dumazet@...il.com> wrote ----
>  > >  > On Thu, 2017-01-19 at 17:41 +0100, Fredrik Markstrom wrote:
>  > >  > > Hello,
>  > >  > >
>  > >  > > I've noticed an inconsistency between how physical ethernet and
>  > > veth handles mtu.
>  > >  > >
>  > >  > > If I setup two physical interfaces (directly connected) with
>  > > different mtu:s, only the size of the outgoing packets are limited by
>  > > the mtu. But with veth a packet is dropped if the mtu of the receiving
>  > > interface is smaller then the packet size.
>  > >  > >
>  > >  > > This seems inconsistent to me, but maybe there is a reason for
>  > > it ?
>  > >  > >
>  > >  > > Can someone confirm if it's a deliberate inconsistency or just a
>  > > side effect of using dev_forward_skb() ?
>  > >  >
>  > >  > It looks this was added in commit
>  > >  > 38d408152a86598a50680a82fe3353b506630409
>  > >  > ("veth: Allow setting the L3 MTU")
>  > >  >
>  > >  > But what was really needed here was a way to change MRU :(
>  > >
>  > > Ok, do we consider this correct and/or something we need to be
>  > > backwards compatible with ? Is it insane to believe that we can fix
>  > > this "inconsistency" by removing the check ?
>  > >
>  > > The commit message reads "For consistency I drop packets on the
>  > > receive side when they are larger than the MTU", do we know what it's
>  > > supposed
>  > > to be consistent with or is that lost in history ?
>  >
>  > There is no consistency among existing Ethernet drivers.
>  >
>  > Many ethernet drivers size the buffers they post in RX ring buffer
>  > according to MTU.
>  >
>  > If MTU is set to 1500, RX buffers are sized to be about 1536 bytes,
>  > so you wont be able to receive a 1700 bytes frame.
>  >
>  > I guess that you could add a specific veth attribute to precisely
>  > control MRU, that would not break existing applications.
>
> Ok, I will propose a patch shortly. And thanks, your response time is
> awesome !

But why do you want to configure MRU?
What is the problem with setting MTU instead.

Toshiaki Makita