Inside a MPC5748G project I am using the "Automatic IP-header checksum generation" feature.
During init I have
// Acceleration functions Tx - checksum generate
ENET.TFWR.B.STRFWD = 1; // Must be set to use the checksum feature
// Store and forward on the Transmit path, set STR_FWD to ‘1’. In this case, the
// MAC starts to transmit data only when a complete frame is stored in the Transmit FIFO.
ENET.TACC.B.PROCHK = 1; // Enables insertion of protocol checksum.
// 0 - Checksum not inserted
// 1 - If an IP frame with a known protocol is transmitted, the checksum is inserted automatically into the
// frame. The checksum field must be cleared. The other frames are not modified.
ENET.TACC.B.IPCHK = 1; // Enables insertion of IP header checksum.
// 0 - Checksum is not inserted.
// 1 - If an IP frame is transmitted, the checksum is inserted automatically. The IP header checksum field
// must be cleared. If a non-IP frame is transmitted the frame is not modified.
and packets send to ENET has 0x00 0x00 bytes for IP header checksum, so hardware can update it. Everything seems to work fine for all packets, except those which should have an IP header checksum equal to 0x0000, instead their checksum is 0xFFFF.
On the other hand according to specification RFC1624, it can not be 0xFFFF
Since there is guaranteed to be at least onenon-zero field in the IP header, and the checksum field in theprotocol header is the complement of the sum, the checksum field can
never contain ~(+0), which is -0 (0xFFFF).
Here is an example of a frame that leads to IP header checksum equal to 0xFFFF ( I have no idea why Wireshark marks it as correct, may be because total sum at the end is also zero)
Calculating IP header checksum (values in yellow):
0x0000 // header checksum replaced with zeroes
- - - - - - - -
adding carrys: 2+FFFD = FFFF
IP header checksum = ~(0xFFFF) = 0x0000
Have anybody observed similar behavior?