[参考译文] AM3352：TI-RTOS 下 AM3352 + KSZ9131RNX 上 FIN 数据包的填充行为

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1532099/am3352-padding-behavior-for-fin-packets-on-am3352-ksz9131rnx-under-ti-rtos

工具/软件：

您好、

我们正在与您联系、以获取有关使用 TI AM3352 和 Microchip KSZ9131RNX 进行网络通信控制的建议。

我们目前正在开发千兆位以太网功能、在测试 AM3352 控制的 KSZ9131RNX 时、我们发现了一个问题、即从评估板到 PC 的 TCP/IP 通信有时无法提供预期数据。

【通信类型】
TCP/IP

【发现的问题】
通过 TCP/IP 将数据从评估板发送到 PC 时、FIN 数据包会出现在 Wireshark 捕获中、但它无法到达 PC 上的应用。 该recv()功能保持在等待状态。

【详细信息】
我们在 PC 上使用 VC ++创建了一个简单的应用、通过插座与评估板进行通信。 流程如下：

1. TCP 套接字连接成功（交换 SYN 和 ACK）

2. 正常接收来自评估板的 1024 字节数据

3. →板发送 PC 应用未接收到的 FIN 数据包（仍在等待） recv()

4. Wireshark 显示确实发送了 Len=0 的[FIN、ACK]数据包

5. 复位电路板会导致发送 RST 数据包、recv()然后该功能退出

在电路板端、我们观察到丢弃了小于 60 字节的数据包、因此我们手动为此类数据包添加填充 0x00（如 ARP 和 RST）以满足以太网的最小帧大小。

【已执行测试】
当我们添加了这两个填充数据并相应地更新了 IP 标头的总长度字段时、PC 可以成功接收 FIN 数据包。
在本例中、Wireshark 将[FIN、ACK]数据包显示为 Len=6（匹配填充）、的返回值recv()为 0。

但是、如果我们在不修改 IP 标头的情况下仅添加填充、则 Wireshark 仍然显示 Len=0、并且 PC 不接收数据包。

【问题】
手动将数据添加到 FIN 数据包会导致非自然状态、其中 FIN 数据包承载有效负载数据。
AM3352 或 KSZ9131 是否可以在发送小于 60 字节的以太网帧时自动添加填充、从而无需在软件中修改 IP 标头即可正确传输此类小尺寸数据包？

我们感谢您的指导。

此致、
Conor