RE: [PATCH] ipvs: sctp: fix checksumming on snat and dnat handlers

To: "Simon Horman" <horms@xxxxxxxxxxxx>, "Pablo Neira Ayuso" <pablo@xxxxxxxxxxxxx>
Subject: RE: [PATCH] ipvs: sctp: fix checksumming on snat and dnat handlers
Cc: <lvs-devel@xxxxxxxxxxxxxxx>, <netdev@xxxxxxxxxxxxxxx>, <netfilter-devel@xxxxxxxxxxxxxxx>, "Wensong Zhang" <wensong@xxxxxxxxxxxx>, "Julian Anastasov" <ja@xxxxxx>, "Daniel Borkmann" <dborkman@xxxxxxxxxx>
From: "David Laight" <David.Laight@xxxxxxxxxx>
Date: Wed, 6 Feb 2013 09:18:53 -0000
> From: Daniel Borkmann <dborkman@xxxxxxxxxx>
> In our test lab, we have a simple SCTP client connecting to a SCTP
> server via an IPVS load balancer. On some machines, load balancing
> works, but on others the initial handshake just fails, thus no
> SCTP connection whatsoever can be established!
> We observed that the SCTP INIT-ACK handshake reply from the IPVS
> machine to the client had a correct IP checksum, but corrupt SCTP
> checksum when forwarded, thus on the client-side the packet was
> dropped and an intial handshake retriggered until all attempts
> run into the void.
> To fix this issue, this patch i) adds a missing CHECKSUM_UNNECESSARY
> after the full checksum (re-)calculation (as done in IPVS TCP and UDP
> code as well), ii) calculates the checksum in little-endian format
> (as fixed with the SCTP code in commit 4458f04c: sctp: Clean up sctp
> checksumming code) and iii) refactors duplicate checksum code into a
> common function. Tested by myself.

If the NAT code has only modified a few bytes inside one of the SCTP
chunks, then the crc can be modified by knowing the changed bits and
the number of bytes to the end of the chunk (without looking at
any other data bytes).
That would (probably) be faster (may not really matter for INIT-ACK.


To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

<Prev in Thread] Current Thread [Next in Thread>