On 27.04.2020 23:12, Florent Fourcot wrote: > Hello Eric, Hello Heiner, > > Just for a small follow-up on your questions and current status on our side > for this strange topic: > > * As explained by Charles, the setup includes a mix of macvlan + vlan. So > 802.1q frames are not a typo in the topic (in our real case, the second > macvlan interface is sent to a network namespace, but it does not matter for > the current issue). > > * We tested the same setup with other networking driver (bnx2, tg3) with > tx-checksum enabled (exactly same configuration than the failing one on r8169 > for checksum offloading), and it's perfectly working. > > * Packets are seen as valid by tcpdump on the sender (buggy) host. > > * Multicast *and* unicast packets are buggy. We detected it first on > multicast (since the relevant hardware was sending RIP packets), but all > tcp/udp packets are corrupted. ICMP packets are valid. > > * We expected as well a "simple" checksum failure, but it does not look so > simple. Something, on our opinion probably the driver or hardware, is > corrupting the packet. > > * Experimental patches from Heiner are not solving issue. > > * We have the same behavior on at least RTL8168d/8111d, RTL8169sc/8110sc and > RTL8168h/8111h variants. > > > As proposed by Heiner, we will try to debug step by step packet path inside > the kernel to find where it's become corrupted. But it looks time consuming > for people like us, not really experts in driver development. If you have any > tips or ideas concerning this topic, it could help us a lot. > > Best regards, >
Previously in this thread you sent an example of a corrupted packet, a LLC packet. For my understanding, is LLC configured in your config? See net/llc/Kconfig. If yes, then does the issue also occur with this option disabled? Heiner
