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  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]
Date:   Wed, 11 May 2022 00:55:43 +0200
From:   Hauke Mehrtens <>
To:     Luiz Angelo Daros de Luca <>
Cc:     "David S. Miller" <>,
        Jakub Kicinski <>,
        Linus Walleij <>,
        Alvin Šipraga <>,
        Andrew Lunn <>,
        Vivien Didelot <>,
        Florian Fainelli <>,
        Vladimir Oltean <>,
        "open list:NETWORKING DRIVERS" <>,
        Arınç ÜNAL <>
Subject: Re: [PATCH 0/4] net: dsa: realtek: rtl8365mb: Add SGMII and HSGMII

On 5/9/22 08:28, Luiz Angelo Daros de Luca wrote:
>> 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.

Yes this is the default checksum. I see the same checksum when listening 
on my laptop for packets it sends out and where the NIC does checksum 

>> 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:
> (there are some interesting discussions)
> (merged)

Thanks for the links.

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

Thanks for the tip to remove the checksum offloading before adding the 
device to the bridge, I was already wondering why it did not work when I 
deactivated the checksum offloading later.

Thanks for the link. I also have one device with a MT7531 switch, but it 
is sued in production. I will check this in the next days.

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

I accidentally tested TCP Large receive offload. ;-) The driver has a 
special DMA flag for to tell the MAC that there is a Mediatek tag in the 

>> 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:
>> Here are some information about the source:
>> 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(-)


Powered by blists - more mailing lists