加载失败
原帖讨论的是一种很难定位的网络故障：某些包在特定环境下会被丢弃，线索集中在 Intel 网卡、驱动和 UDP checksum 上。评论里补充了 RFC 1122 规定的特殊行为：UDP checksum 若算出 0，必须以 0xFFFF 发送，这让 0x0000 和 0xFFFF 成为实现上的边界值。另一些人分享了类似案例，防火墙的 DoS protection、ALG（Application Layer Gateway，应用层网关）和 NIC 的 Rx offloading 叠在一起，会让同一个包有时能过、有时被丢。大家还拿 Factorio 的 FFF（Friday Facts，开发日志）和 Intel Linux NIC driver 的相关讨论作对照，说明这类问题常常需要跨协议、驱动和硬件一起排查。
讨论首先聚焦在 checksum 为什么会异常地变成全 0 或全 F。有人引用 RFC 1122 解释：UDP checksum 如果算出 0，就必须在报文里写成 0xFFFF，因为在 1's complement 里两者等价。评论认为，一旦实现里把这两个值当成普通二补码处理，就会只在这两个边界值上出错，表现为偶发丢包或某些设备直接拒包。
很多人把问题指向 NIC 的 checksum offloading 或驱动 bug，而不是协议本身。网卡硬件代替 CPU 计算或验证 checksum，本来是为了提速，但在某些 Intel、Broadcom 网卡上，特定路径会把合法包误判成坏包。有人提到关掉 Rx/Tx offloading 后问题就消失，说明这类故障常常卡在驱动和硬件边界条件上。
还有人分享，真正让问题变得难查的，是防火墙、网关和网卡同时在捣乱。一个案例里，join 包连续发送 4 次先触发了防火墙的 DoS protection，又被 ALG（Application Layer Gateway，应用层网关）干预，最后才发现 Intel NIC 的 Rx offloading 才是根因。这个故事说明，‘网络不通’常常不是单点故障，而是多层设备叠加后才暴露出来。
有人建议，在不想手工反汇编和 tracing Intel Windows driver 的情况下，可以试试让 AI 帮忙做这类重复而繁琐的工作。这个问题的优点是定义很清楚、验证也容易，只要能缩小可疑路径，就能快速判断是不是驱动或硬件在作怪。评论还提到当天就有一个类似的 Intel Linux NIC driver 讨论串，说明跨平台比对线索很有价值。
有人顺带夸赞 Factorio 团队的 FFF（Friday Facts，开发日志）写得够细，愿意把系统机制和 bug 细节讲透，而不只是给结论。对这类读者来说，真正有价值的是把 checksum、offloading、协议实现和实际故障串成一条完整链路。也正因为这种写法，大家才更能理解为什么一个网络问题会卡在这么不起眼的边角值上。
UDP checksum: UDP 数据报头里的校验和字段，用于检测传输错误；在 IPv4 中可选，但计算结果为 0 时要以 0xFFFF 表示。
1's complement: 一补码算术，Internet checksum 的计算基础；在这种规则下，0x0000 和 0xFFFF 被视为等价。
checksum offloading / Rx offloading: 由网卡硬件代替 CPU 计算或验证 checksum 的机制；性能更好，但驱动或硬件有 bug 时容易误判包是否合法。