RX checksum offloading problem

[Bjoern A. Zeeb]

On 02 May 2014, at 10:22 , Michael Tuexen <Michael.Tuexen at lurchi.franken.de> wrote:

> Dear all,
> 
> during testing I found that FreeBSD head (on a raspberry pi) accepts SCTP packet
> with bad checksums. After debugging this I figured out that this is a problem with
> the csum_flags defined in mbuf.h.
> 
> The SCTP code on its input path checks for CSUM_SCTP_VALID, which is defined in mbuf.h:
> #define CSUM_SCTP_VALID         CSUM_L4_VALID
> This makes sense: If CSUM_SCTP_VALID is set in csum_flags, the packet is considered
> to have a correct checksum.
> 
> For UDP and TCP some drivers calculate the UDP/TCP checksum and set CSUM_DATA_VALID in
> csum_flags to indicate that the UDP/TCP should consider csum_data to figure out if
> the packet has a correct checksum. The problem is that CSUM_DATA_VALID is defined as
> #define CSUM_DATA_VALID         CSUM_L4_VALID
> In this case the semantic is not that the packet has a valid checksum, but the csum_data
> field contains information.
> 
> Now the following happens (on the raspberry pi the driver used is
> dev/usb/net/if_smsc.c
> 
> 1. A packet is received and if it is not too short, the checksum computed
>   is stored in csum_data and the flag CSUM_DATA_VALID is set. This happens
>   for all IP packets, not only for UDP and TCP packets.
> 2. In case of SCTP packets, the SCTP interprets CSUM_DATA_VALID as CSUM_SCTP_VALID
>   and accepts the packet. So no SCTP checksum check ever happened.
> 
> Alternatives to fix this:
> 
> 1. Change all drivers to set CSUM_DATA_VALID only in case of UDP or TCP packets, since
>   it only makes sense in these cases.

Wait, or for SCTP in cad the crc32 (I think it was)  was actually checked but not otherwise.   This is how it should be imho.  It seems like a driver bug.


— 
Bjoern A. Zeeb             "Come on. Learn, goddamn it.", WarGames, 1983