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: <CAJq09z7+bDpMShTxuOvURmp272d-FVDNaDpx1_-qjuOZOOrS3g@mail.gmail.com>
Date:   Mon, 9 May 2022 03:28:37 -0300
From:   Luiz Angelo Daros de Luca <luizluca@...il.com>
To:     Hauke Mehrtens <hauke@...ke-m.de>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Alvin Šipraga <alsi@...g-olufsen.dk>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>,
        Arınç ÜNAL <arinc.unal@...nc9.com>
Subject: Re: [PATCH 0/4] net: dsa: realtek: rtl8365mb: Add SGMII and HSGMII support

> This was tested on a Buffalo WSR-2533DHP2. This is a board using a
> Mediatek MT7622 SoC and its 2.5G Ethernet MAC connected over a 2.5G
> HSGMII link to a RTL8367S switch providing 5 1G ports.
> This is the only board I have using this switch.
>
> With the DSA_TAG_PROTO_RTL8_4 tag format the TCP checksum for all TCP
> send packets is wrong. It is set to 0x83c6. The mac driver probably
> should do some TCP checksum offload, but it does not work.

0x83c6 might be yout tcp pseudo ip header sum.

> When I used the DSA_TAG_PROTO_RTL8_4T tag format the send packets are
> ok, but it looks like the system does TCP Large receive offload, but
> does not update the TCP checksum correctly. I see that multiple received
> TCP packets are combined into one (using tcpdump on switch port on
> device). The switch tag is also correctly removed. tcpdump complains
> that the checksum is wrong, it was updated somewhere, but it is wrong.
>
> Does anyone know what could be wrong here and how to fix this?

The good news, it is a known problem:

https://patchwork.kernel.org/project/netdevbpf/patch/20220411230305.28951-1-luizluca@gmail.com/
(there are some interesting discussions)
https://patchwork.kernel.org/project/netdevbpf/patch/20220416052737.25509-1-luizluca@gmail.com/
(merged)

The bad news, there is no way to enable checksum offload with
mediatek+realtek. You'll need to disable almost any type of offload.
For any tag before the IP header, if your driver/HW does not support a
way to set where the IP header starts and the offload HW does not
understand the tag protocol, the offload HW will keep the pseudo ip
header sum. And for tags after the payload, the offload HW will blend
the tag with the payload, generating bad checksums when the switch
removes the tag.

You can do that from userland, using ethtool on the master port before
the bridge is up, or patching the driver. You can try this patch
(written for MT7620 but it is easy to adapt it to upstream
mtk_eth_soc.c).
https://github.com/luizluca/openwrt/commit/d799bd363f902bf3b9c595972a1b9280a0b61dca
. I never submitted that upstream because I don't have the HW to test
it (Arinç tested a modified version in an MT7621) and I didn't
investigate how much those extra ifs in ndo_features_check will cost
in performance when the driver does support the tag (using a mediatek
switch).

And the DSA_TAG_PROTO_RTL8_4T already paid off. It was added exactly
as a way to test checksum errors. Probably no offload will work for
tags that are after the payload if the offload HW does not already
know that tag (e.g. same vendors). DSA_TAG_PROTO_RTL8_4T works because
it calculates the checksum in software before the tag is added.
However, during my tests, I never tested TCP Large receive offload.

> This uses the rtl8367s-sgmii.bin firmware file. I extracted it from a
> GPL driver source code with a GPL notice on top. I do not have the
> source code of this firmware. You can download it here:
> https://hauke-m.de/files/rtl8367/rtl8367s-sgmii.bin
> Here are some information about the source:
> https://hauke-m.de/files/rtl8367/rtl8367s-sgmii.txt
>
> This file does not look like intentional GPL. It would be nice if
> Realtek could send this file or a similar version to the linux-firmware
> repository under a license which allows redistribution. I do not have
> any contact at Realtek, if someone has a contact there it would be nice
> if we can help me on this topic.
>
> Hauke Mehrtens (4):
>   net: dsa: realtek: rtl8365mb: Fix interface type mask
>   net: dsa: realtek: rtl8365mb: Get chip option
>   net: dsa: realtek: rtl8365mb: Add setting MTU
>   net: dsa: realtek: rtl8365mb: Add SGMII and HSGMII support
>
>  drivers/net/dsa/realtek/rtl8365mb.c | 444 ++++++++++++++++++++++++++--
>  1 file changed, 413 insertions(+), 31 deletions(-)
>
> --
> 2.30.2
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ