• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 96 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: Padding Behavior for FIN Packets on AM3352 + KSZ9131RNX under TI-RTOS

Conor
Guru 12155 points
Part Number: AM3352

Tool/software:

Hi,

We are contacting you for advice regarding network communication control using the TI AM3352 and Microchip KSZ9131RNX.

We are currently developing Gigabit Ethernet functionality, and while testing the KSZ9131RNX controlled by AM3352, we have observed an issue where TCP/IP communication from the evaluation board to a PC sometimes fails to deliver the expected data.

[Communication Type]
TCP/IP

[Observed Issue]
When sending data from the evaluation board to the PC via TCP/IP, the FIN packet appears in the WireShark capture, but it does not reach the application on the PC. The recv() function remains in a waiting state.

[Details]
We created a simple application in VC++ on the PC to communicate with the evaluation board via sockets. The flow is as follows:

  1. TCP socket connects successfully (SYN and ACK are exchanged)

  2. 1024 bytes of data from the evaluation board are received normally

  3. The evaluation board sends a FIN packet → not received by the PC app (recv() remains waiting)

  4. WireShark shows the [FIN,ACK] packet with Len=0 is indeed sent

  5. Resetting the board causes an RST packet to be sent, and the recv() function then exits

On the board side, we observed that packets smaller than 60 bytes are dropped, so we manually add 0x00 padding to such packets (like ARP and RST) to meet the Ethernet minimum frame size.

[Test Performed]
When we added both padding data and updated the IP header’s Total Length field accordingly, the PC could successfully receive the FIN packet.
In this case, WireShark showed the [FIN,ACK] packet as Len=6 (matching the padding), and the return value of recv() was 0.

However, if we added only the padding without modifying the IP header, WireShark still shows Len=0, and the PC does not receive the packet.

[Question]
Manually adding data to a FIN packet results in an unnatural state where a FIN packet carries payload data.
Is there any way for the AM3352 or the KSZ9131 to automatically add padding when sending Ethernet frames smaller than 60 bytes, so that such low-size packets are properly transmitted without needing to modify the IP header in software?

We would appreciate your guidance.

Sincerely,
Conor

  • 0
    TI__Guru 59045 points

    Hello Conor,

    We can no longer support TI-RTOS based SW development for AM335x. Please refer to this announcement and find existing resources there.

    Regards,

    Jianzhong

  • 0 in reply to Jianzhong Xu
    Guru 12155 points

    Hi Xu,

    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

  • 0 in reply to Conor
    TI__Guru 59045 points

    Ho Conor,

    Unfortunately, we do not have expertise in the TI-RTOS NDK stack any more.

    Regards,

    Jianzhong