netdev - Re: Issue with r8169 (using r8168 for now) driving 8111E

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: <Ytx7nc3FosXV6ptC@electric-eye.fr.zoreil.com>
Date:   Sun, 24 Jul 2022 00:52:13 +0200
From:   Francois Romieu <romieu@...zoreil.com>
To:     Mason Loring Bliss <mason@...sses.org>
Cc:     Realtek linux nic maintainers <nic_swsd@...ltek.com>,
        netdev@...r.kernel.org, hkallweit1@...il.com
Subject: Re: Issue with r8169 (using r8168 for now) driving 8111E

(more than current r8169 maintainer Cced -> Heiner Kallweit)

Mason Loring Bliss <mason@...sses.org> :
> Hi all. I was happily running Debian Buster with Linux 4.19.194 driving a
> pair of 8111E NICs as included on this board:
> 
>     https://www.aaeon.com/en/p/mini-itx-emb-cv1
> 
> I upgraded to Debian Bullseye running 5.10.127 and started seeing this
> popping up regularly in dmesg, with the status varying:
> 
>     r8169 0000:03:00.0 eth1: Rx ERROR. status = 3529c123

This message was emitted as INFO in 4.19 whereas 5.10 considers it WARN.

You may check/enable the relevant message level with ethtool. I would
naïvely expect v4.19 to silently detect the error.

For your information, the content of the faulty descriptor word is
summarized below:

OWN  0
EOR  0
FS   1 (first segment)
LS   1 (last segment)

MAR  0 (multicast)
PAM  1 (physical address match)
BAR  0
RESV 1 (reserved)

RESV 1 (reserved)
RWT  0
RES  1 (receive error summay)
RUNT 0

CRC  1 (CRC error)
UDP  0
TCP  0
IP   1 (IP checksum failure)

UDPF 1 (udp checksum failure)
TCPF 1 (tcp checksum failure)

Frame length 0x123 -> 291

The driver should receive and process this kind of CRC errored packet since
79d0c1d26e1eac0dc5b201e66b65cc5e4e706743 ("r8169: Support RX-FCS flag.")
provided ethtool was not used to disable it (see -k/-K and rx-fcs/rx-all).
tcpdump may thus help to identify some pattern in the packet.

HTH.

-- 
Ueimor