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: <1d159325-3b64-4f50-8f95-b88f6638e19d@bp.renesas.com>
Date: Tue, 13 Aug 2024 13:53:06 +0100
From: Paul Barker <paul.barker.ct@...renesas.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Sergey Shtylyov <s.shtylyov@....ru>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>,
 Niklas Söderlund <niklas.soderlund+renesas@...natech.se>,
 Biju Das <biju.das.jz@...renesas.com>,
 Claudiu Beznea <claudiu.beznea.uj@...renesas.com>,
 Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
 Mitsuhiro Kimura <mitsuhiro.kimura.kc@...esas.com>, netdev@...r.kernel.org,
 linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [net-next PATCH 1/2] net: ravb: Fix maximum MTU for GbEth devices

On 18/06/2024 01:07, Jakub Kicinski wrote:
> On Sat, 15 Jun 2024 11:30:37 +0100 Paul Barker wrote:
>> The datasheets for all SoCs using the GbEth IP specify a maximum
>> transmission frame size of 1.5 kByte. I've confirmed through internal
>> discussions that support for 1522 byte frames has been validated, which
>> allows us to support the default MTU of 1500 bytes after reserving space
>> for the Ethernet header, frame checksums and an optional VLAN tag.
> 
> 
> But what's the user impact? If we send a bigger frame the IP will hang?
> Drop the packet? Something else?
> "Validated" can also mean "officially supported" sometimes vendors just
> say that to narrow down the test matrix :(

Apologies for the late response.

I was able to hang the GbEth IP by attempting to transmit a 2kB frame,
no error condition was raised by the hardware but no further packets
could be sent or received. I was able to successfully send a 1.8kB
frame, but there is no guarantee that this will always work. The RZ/G2L
datasheet states that frames of up to 1.5kB can be transmitted so I
clarified with the HW team that 1522 bytes was ok to allow for the
default MTU plus headers.

I'm going to submit v2 of this series as bugfixes against net (instead
of net-next) shortly.

Thanks,

-- 
Paul Barker

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ