• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 97 subscribers
  • Views 57 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3352: TCP FIN packet not received by Windows recv() – MAC padding behavior confirmation

Conor
Guru 12125 points
Part Number: AM3352

Tool/software:

Hi,

We are developing a Gigabit Ethernet system using the AM3352 processor and KSZ9131RNX PHY. We are facing an issue where a FIN packet sent from the AM3352 is observed in Wireshark as a [FIN, ACK] Len=0 frame, but it is not received by a Windows application using the standard recv() function.

Upon further investigation, we noticed that when the transmitted frame length is under 60 bytes, it is dropped unless manually padded with 0x00 bytes to meet the 60-byte minimum. If we manually add padding and also update the IP header total length field to include the padding, the PC receives the FIN packet correctly (though recv() returns 0 bytes, which is expected).
However, if we only pad the frame at the tail without updating the IP header length field, the PC does not recognize the FIN packet.

Based on the IEEE 802.3 standard, we understand that Ethernet MAC should automatically pad frames smaller than 64 bytes. We also understand that the PHY (KSZ9131RNX) does not perform this padding.

To confirm our understanding, could you please verify the following points:

  1. Does the CPSW (Ethernet MAC) in the AM3352 automatically pad Ethernet frames to meet the 64-byte minimum when no payload is present, such as for a FIN packet?

  2. If not, is there a configuration in the AM335x Ethernet driver that enables automatic MAC-level padding?

Best regards,
Conor

  • 0
    Guru 12125 points

    Hi,

    Additional research was conducted.

    We are facing an issue where, during TCP communication from our evaluation board to a PC, the FIN packet is not properly received by the PC application when the total frame size is less than the minimum Ethernet frame size (60 bytes). Although the [FIN, ACK] packet is visible in WireShark, the recv() function on the PC side does not return and remains blocked. To work around this issue, we are currently adding dummy padding data on the application side to meet the 60-byte minimum size. However, this requires manually adjusting the IP header’s Total Length field, which complicates the implementation.

    We have reviewed the NDK documentation and found a configuration option called “Minimum Send Size”, but it appears to apply primarily to UDP traffic. We would like to clarify the following points regarding support for automatic padding:

    [Questions]

    1. Does the NDK’s Minimum Send Size setting also apply to TCP traffic, including control packets like FIN?

    2. Is there any mechanism within the CPSW driver or NDK stack on AM3352 + TI-RTOS that automatically pads outgoing Ethernet frames to meet the 60-byte minimum length?

    I understand that TI-RTOS is no longer supported, but I would appreciate it if you could investigate as much as possible to resolve the issue as soon as possible.

    Conor