以太网的ICMP校验和计算前为什么没有清0

shzdf123

STM32F4以太网，DMA发送描述符在校验和插入控制时，有一个选项：“使能IP报头校验和以及有效负载校验和的计算与插入，并在硬件中计算伪报头校验和”。此类校验和计算三步曲，一是清0校验和初始值，二是校验和计算，三是加载校验和。在TCP/UDP时都完美执行了此三步曲，但在ICMP时第一步清0校验和初始值并未得到执行，而是要求输入的ICMP协议校验和值必须为0。不知道为什么这样设计？是有什么我不知道的原因吗？有哪位大神知道此GET？

eric2013

楼主的这个看的是那个驱动或者手册上说的，我一直用的这个

全都开了，统一设计的

[C] 纯文本查看 复制代码

/* Driver Capabilities */
static const ARM_ETH_MAC_CAPABILITIES DriverCapabilities = {
  (EMAC_CHECKSUM_OFFLOAD != 0) ? 1U : 0U,   /* checksum_offload_rx_ip4  */
  (EMAC_CHECKSUM_OFFLOAD != 0) ? 1U : 0U,   /* checksum_offload_rx_ip6  */
  (EMAC_CHECKSUM_OFFLOAD != 0) ? 1U : 0U,   /* checksum_offload_rx_udp  */
  (EMAC_CHECKSUM_OFFLOAD != 0) ? 1U : 0U,   /* checksum_offload_rx_tcp  */
  (EMAC_CHECKSUM_OFFLOAD != 0) ? 1U : 0U,   /* checksum_offload_rx_icmp */
  (EMAC_CHECKSUM_OFFLOAD != 0) ? 1U : 0U,   /* checksum_offload_tx_ip4  */
  (EMAC_CHECKSUM_OFFLOAD != 0) ? 1U : 0U,   /* checksum_offload_tx_ip6  */
  (EMAC_CHECKSUM_OFFLOAD != 0) ? 1U : 0U,   /* checksum_offload_tx_udp  */
  (EMAC_CHECKSUM_OFFLOAD != 0) ? 1U : 0U,   /* checksum_offload_tx_tcp  */
  (EMAC_CHECKSUM_OFFLOAD != 0) ? 1U : 0U,   /* checksum_offload_tx_icmp */
  (ETH_MII != 0) ?
  ARM_ETH_INTERFACE_MII :
  ARM_ETH_INTERFACE_RMII,                   /* media_interface          */
  0U,                                       /* mac_address              */
  1U,                                       /* event_rx_frame           */
  1U,                                       /* event_tx_frame           */
  1U,                                       /* event_wakeup             */
  0U                                        /* precision_timer          */
#if (defined(ARM_ETH_MAC_API_VERSION) && (ARM_ETH_MAC_API_VERSION >= 0x201U))
, 0U                                        /* reserved bits            */
#endif
};

shzdf123

    我明白在以太网驱动和第三方软件之间进行适合的配置，可以规避此类问题。但不明白为什么ST这样设计，经过查询，F4，H7，H5都是此类设计。如果这是一个BUG，最多体现在F4上，后续的H7，H5应该很容易解决，但就是没有解决。所以担心是不是自己有哪个地方的知识没有掌握。
    IP手册上的描述：For ICMP-over-IPv4 packets, the Checksum field in the ICMP packet must always be 16'0000 in both modes, because pseudo-headers are not defined for such packets. If it does not equal 16'0000, an incorrect checksum may be inserted into the packet.
    哎，不明白为什么这种设计。这个设计导致L3层的TCP/UDP都没法硬件校验和了。否则就会PING不通，因此校验和失败。

eric2013

shzdf123 发表于 2024-10-8 19:26
我明白在以太网驱动和第三方软件之间进行适合的配置，可以规避此类问题。但不明白为什么ST这样设计，经 ...

这个问题还真没留意过，后面我也对比其它厂家的看看。

这种的也正常，属于祖传设计，省钱，同一IP核，不用花钱买了。

勘误手册也看了，不是bug，他就是这么设计的。

shzdf123

是的。我也看了IP核的资料，F4/H7/H5都是这种设计。好奇怪，这个就把硬件自动校验枪毙了，否则PING协议就不通了。