netdev - Re: Re: Re: Re: [PATCH net-next v4 11/11] net: dsa: realtek: rtl8365mb: multiple cpu ports, non cpu extint

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: <CAJq09z5sJJO_1ogPi5+PhHkBS9ry5_oYctMhxu68GRNqEr3xLw@mail.gmail.com>
Date:   Sat, 29 Jan 2022 22:54:02 -0300
From:   Luiz Angelo Daros de Luca <luizluca@...il.com>
To:     Frank Wunderlich <frank-w@...lic-files.de>
Cc:     Alvin Šipraga <ALSI@...g-olufsen.dk>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "vivien.didelot@...il.com" <vivien.didelot@...il.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "olteanv@...il.com" <olteanv@...il.com>,
        "arinc.unal@...nc9.com" <arinc.unal@...nc9.com>
Subject: Re: Re: Re: Re: [PATCH net-next v4 11/11] net: dsa: realtek:
 rtl8365mb: multiple cpu ports, non cpu extint

> I suggested it might be checksum problem because I'm also affected. In
> my case, I have an mt7620a SoC connected to the rtl8367s switch. The
> OS offloads checksum to HW but the mt7620a cannot calculate the
> checksum with the (EtherType) Realtek CPU Tag in place. I'll try to
> move the CPU tag to test if the mt7620a will then digest the frame
> correctly.

I implemented a new DSA tag (rtl8_4t, with "t" as in trailing) that
puts the DSA tag before the Ethernet CRC (the switch supports both).
With no tag in the mac layer, mediatek correctly calculated the ip
checksum. However, mediatek SoC included the extra bytes from the DSA
tag in the TCP checksum, even if they are after the ip length.

This is the packet leaving the OS:

0000   04 0e 3c fc 4f aa 50 d4 f7 33 15 8a 08 00 45 10
0010   00 3c 00 00 40 00 40 06 b7 58 c0 a8 01 01 c0 a8
0020   01 02 00 16 a1 50 80 da 39 e9 b2 2a 23 cf a0 12
0030   fe 88 83 82 00 00 02 04 05 b4 04 02 08 0a 01 64
0040   fb 28 66 42 e0 79 01 03 03 03 88 99 04 00 00 20
0050   00 08

TCP checksum is at 0x0032 with 0x8382 is the tcp checksum
DSA Tag is at 0x4a with 8899040000200008

This is what arrived at the other end:

0000   04 0e 3c fc 4f aa 50 d4 f7 33 15 8a 08 00 45 10
0010   00 3c 00 00 40 00 40 06 b7 58 c0 a8 01 01 c0 a8
0020   01 02 00 16 a1 50 80 da 39 e9 b2 2a 23 cf a0 12
0030   fe 88 c3 e8 00 00 02 04 05 b4 04 02 08 0a 01 64
0040   fb 28 66 42 e0 79 01 03 03 03

TCP checksum is 0xc3e8, but the correct one should be 0x50aa
If you calculate tcp checksum including 8899040000200008, you'll get exactly
0xc3e8 (I did the math).

So, If we use a trailing DSA tag, we can leave the IP checksum offloading on
and just turn off the TCP checksum offload. Is it worth it?

Is it still interesting to have the rtl8_4t merged?

Regards,