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: <Y1a4no+U1cbXAWLi@lunn.ch>
Date:   Mon, 24 Oct 2022 18:09:02 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Sergei Antonov <saproj@...il.com>
Cc:     Vladimir Oltean <olteanv@...il.com>, netdev@...r.kernel.org,
        davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
        pabeni@...hat.com
Subject: Re: [PATCH v4 net-next] net: ftmac100: support mtu > 1500

On Mon, Oct 24, 2022 at 06:50:31PM +0300, Sergei Antonov wrote:
> On Wed, 19 Oct 2022 at 21:42, Vladimir Oltean <olteanv@...il.com> wrote:
> >
> > On Wed, Oct 19, 2022 at 09:36:21PM +0300, Sergei Antonov wrote:
> > > On Wed, 19 Oct 2022 at 19:55, Vladimir Oltean <olteanv@...il.com> wrote:
> > > >
> > > > On Wed, Oct 19, 2022 at 07:20:58PM +0300, Sergei Antonov wrote:
> > > > > The ftmac100 controller considers some packets FTL (frame
> > > > > too long) and drops them. An example of a dropped packet:
> > > > > 6 bytes - dst MAC
> > > > > 6 bytes - src MAC
> > > > > 2 bytes - EtherType IPv4 (0800)
> > > > > 1504 bytes - IPv4 packet
> > > >
> > > > Why do you insist writing these confusing messages?
> 
> Working on a better version of the patch. And here is another question.
> Unless the flag is set, the controller drops packets bigger than 1518
> (that is 1500 payload + 14 Ethernet header + 4 FCS). So if mtu is 1500
> the driver can enable the controller's functionality (clear the
> FTMAC100_MACCR_RX_FTL flag) and save CPU time. When mtu is less or
> greater than 1500, should the driver do the following:
> if (ftmac100_rxdes_frame_length(rxdes) > netdev->mtu + ETH_HLEN) {
>     drop the packet
> }
> I mean, is it driver's duty to drop oversized packets?

It is not well defined what should happen here. Some drivers will
deliver oversized packets to the stack, some will not.

The main purpose of the MTU is fragmentation on transmission. How do
you break a UDP or TCP PDU up into L2 frames. MTU is not really used
on reception. If the L2 frame is otherwise valid, i doubt the stack
will drop it if it is longer than expected.

     Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ