Fix TCP IPv4 tx checksum length for padded RX frames

[marcusb]

Summary

prvTCPReturnPacket_IPV4() called usGenerateProtocolChecksum() with pxNetworkBuffer->xDataLength as the buffer length. At that point xDataLength still holds the length of the incoming frame — for example, 60 bytes for a SYN that was padded up to the Ethernet minimum. The reply (e.g. a SYNACK with TCP options) is typically longer, so the checksum ended up being computed over the wrong byte range. xDataLength is only updated to the outgoing length a few lines later, at pxNetworkBuffer->xDataLength = ( size_t ) ulLen; pxNetworkBuffer->xDataLength += ipSIZE_OF_ETH_HEADER;.

The IPv6 path (prvTCPReturnPacket_IPV6()) was already correct — it uses ulLen + ipSIZE_OF_ETH_HEADER directly. This change mirrors that in the IPv4 path.

[AniruddhaKanhere]

Thanks for the contribution, @marcusb. Good catch — confirmed the bug by comparing the IPv4 and IPv6 paths. The checksum was indeed being computed over the stale incoming xDataLength rather than the outgoing packet length.
The fix correctly mirrors prvTCPReturnPacket_IPV6() and the unit test is solid.

Tagging @htibosch for review.

LGTM — approving.

[htibosch]

It looks correct to me, but I want to make sure that things went really wrong with the existing release. One moment please.

[htibosch]

I found that the patch doesn't make much a difference: the protocol checksum doesn't change if you add more zeros to the packet.
In the code we are referring to pxNetworkBuffer->xDataLength, but it hasn't been trimmed yet. Sometimes it is 1522 because I use BufferAllocation.1.

Why not move the following 2 lines to above:

    /* Important: tell NIC driver how many bytes must be sent. */
    pxNetworkBuffer->xDataLength = ( size_t ) ulLen;
    pxNetworkBuffer->xDataLength += ipSIZE_OF_ETH_HEADER;

Or if you prefer, here in a patch:
hein_proposal.patch

[htibosch]

PS my patch applies to your branch
I tested all on real hardware (a telnet server) using the main release.

[marcusb]

@htibosch I applied your patch.

The issue is that the received packet is still in the buffer under some circumstances, so it's not only zeros. This caused connections to fail in my project.

[htibosch]

The issue is that the received packet is still in the buffer under some circumstances, so it's not only zeros.

As you may have seen, the driver sometimes allocates a new large buffer ( for sending data ), and it uses a static small buffer for simple messages like an ACK.

Were you also able to test the change?

[htibosch]

@archigup @AniruddhaKanhere Can you please check this PR #1332?
I tested and checked it and it looks good to me.