netdev - Re: Custom Kernel Module for PRP (https://github.com/ramv33/prp) - problem with removal of RCT using skb

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] [day] [month] [year] [list]

Message-ID: <504969a9-94f5-4175-a846-37c39ec0f06c@lunn.ch>
Date: Sun, 2 Jul 2023 15:46:24 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Abhiram V <abhi.raa.man.v@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: Custom Kernel Module for PRP (https://github.com/ramv33/prp) -
 problem with removal of RCT using skb_trim

> To strip the RCT, I call skb_trim as follows (as given in the HSR module):
> 
>              skb_trim(skb, skb->len - PRP_RCTLEN /* 6 */);
> 
> I have used skb_dump both before and after the call to skb_trim and
> verified that the length is being reduced and that the tailroom is
> increased by 6 bytes. The problem is that when I call skb_trim, the
> packet is not received by the upper layers. Without calling skb_trim,
> the packet is received correctly but the RCT is consumed by the
> applications which should not be the case.

Maybe try using:

https://github.com/nhorman/dropwatch

to find out where the packet is being dropped. From where, you should
be able to figure out why it is being dropped.

You might also want to play with ethool -K. Turn off everything, at
both the Tx and Rx node, and see if it makes a difference. e.g. maybe
IP header checksum is being offloaded, and it calculates the CRC
including the RCT.

	Andrew