STM32F769 Ethernet driver reported 60 bytes received by the frame is really 54 bytes

[YZhou.6]

HAL_ETH_ReadData() reported bufflength 60 bytes (damrxdesc-> DESC0.FL shows 64 bytes. looking at the code, bufflength is derived from DESC0.FL - 4. ). However wireshark shows the incoming frame is TCP ACK with no data. So it should be 54 bytes, and I verified the incoming data and the first 54 bytes matches what shows in wireshark.

Same for ping message with small payload. Looks like the driver reports 60 bytes for incoming frames less than 60 bytes

Note the same driver reports correctly for frames with more than 60 bytes (not counting CRC).

Question: what causes the driver to mis-report the frame length? how to fix or work around the problem?

Hardware: STM32F769-DISCO eval board.

[Bob S]

The minimum Ethernet frame size is 64 bytes, so anything smaller gets padded (with zeros, I believe). These pad bytes are ignored by the IP and TCP layers on the receiving end because the IP header fields show the actual IP packet size without Ethernet frame padding. As you mentioned, the 60 (DESC0.FL - 4) is ignoring the 4-byte frame checksum at the end of the Ethernet frame as hardware has already checked that.

[Piranha]

As Bob already said - it is how the Ethernet works and there is no issue. For a more complete explanation read this topic and links from there:

https://community.st.com/s/question/0D53W00000q6eoUSAQ/why-is-lwip-arp-request-message-60-bytes-long-instead-of-42-bytes

[YZhou.6]

Many thanks to Bob and Piranha. Yes that's the problem!