当网络无法工作时

Source: Hacker News

请提供您希望翻译的具体文本内容，我将为您翻译成简体中文并保留原有的格式。

Source: …

旅程

1. 初次尝试 – Windows XP 虚拟机 + TSO

• 在 Windows XP 虚拟机（NAT 网络）中运行 Tyan 旧版 TSO（Tyan System Operator） 软件。
• 软件能够正常安装，但 无法发现任何支持 IPMI 的服务器。
• 手动配置 IPMI 地址同样失败。

2. 原生 Windows 工具

• 尝试使用 ipmiutil (https://ipmiutil.sourceforge.net/)。
• 结果相同——SMDC 从未响应。

3. Windows 10 测试机

• 在一台运行 Windows 10 的旧 PC 上重复测试。
• ipmiutil 仍然拒绝与 SMDC 通信。

4. 转向 Linux

• 将相同硬件重新启动到 Linux 并运行 ipmitool。

• 成功！ ipmitool 能够与 SMDC 通信。

• 在 Linux 主机上再建一个 Windows XP 虚拟机——TSO 软件此时可以正常工作。

5. 防火墙？

• 在所有 Windows 主机上关闭 Windows 防火墙——没有任何变化。

6. 在 Windows 11 上使用 Wireshark 抓包

• 确认 向端口 623 的 UDP 出站流量以及来自 SMDC 的入站回复。
• 抓到了回复报文，但 没有任何应用程序收到它们。

7. PktMon 调查

• 运行 PktMon 查看流量在 Windows 网络栈中的走向。
• 相关日志条目：

DropReason INET: checksum is invalid

• 报文已到达网卡，经过了几层过滤后，TCP/IP 栈因认为 UDP 校验和错误而丢弃了它。
• 然而 Wireshark 报告 IP 和 UDP 校验和 有效。

8. 驱动调优

• 网卡：Intel I211（驱动 e1r68x64.sys）。
• 禁用了 IPv4 的 UDP 接收校验和卸载。

结果： ipmiutil 开始工作，主机上的虚拟机也能够与 SMDC 通信。

• 同样的修复（禁用 IPv4 UDP Rx 校验和卸载）在配备 Intel 82579LM（e1i65x64.sys）的 Windows 10 机器上也解决了问题。
• 一台配备 Killer Wireless 1525 适配器（没有卸载选项）的 Windows 10 笔记本从未受到影响。

这里发生了什么？

• UDP 接收校验和卸载 通常是可靠的；否则 DHCP、DNS 等都会出问题。
• SMDC 的 UDP 包看起来完全正常（≈ 76 字节，没有 VLAN 标签，也没有隧道）。
• Linux（即使在同一块 Intel 网卡上）也能接受它们。
• 当 Windows TCP/IP 协议栈 必须自行验证校验和 时，也认为它们是正常的。

接收校验和卸载的工作原理

1. 硬件 验证入站数据包的校验和，并在接收描述符中设置 有效/无效 标志。
2. 驱动程序 将该标志报告给上层软件。
3. TCP/IP 协议栈 信任该标志，不 重新计算校验和。

因此，唯一合理的解释是 Intel 网卡或其驱动程序错误地将 UDP 校验和报告为无效，导致协议栈丢弃本应有效的数据包。

我是唯一吗？

• 诊断此问题花费了很多时间。
• 最初怀疑是 SMDC（旧的 IPMI 实现可能不稳定），但 Wireshark 证明远端在发送正确的回复。
• PktMon 是关键：它显示了“校验和无效”的丢弃原因，促使对驱动卸载进行调整。

我在网上找到的

• 只有模糊的提及，称校验和卸载会导致神秘的问题。
• 有些建议完全禁用卸载，认为调试成本超过任何性能提升。

TL;DR

• Problem: Windows 10/11 机器使用 Intel NIC 时会丢弃有效的 IPMI UDP 回复，因为 NIC 驱动报告了错误的 UDP 接收校验和状态。
• Fix: 在 NIC 驱动中禁用 IPv4 UDP 接收校验和卸载（例如通过设备管理器 → 高级 → UDP Checksum Offload → Disabled）。
• Result: IPMI 工具（ipmiutil、TSO、虚拟机）在 Tyan SMDC 上能够正常工作。

如果在 Windows 上使用传统 IPMI 设备时遇到类似的“无响应”问题，首先尝试切换 NIC 的校验和卸载设置。

可能的原因

在没有对 Intel Windows 驱动进行反汇编和追踪（我并不想这么做）的情况下，我只能对原因进行推测。我怀疑这与 IP 头部中的 “Packet ID” 字段有关。我甚至了解到有一篇 2013 RFC 6864 重新定义了 ID 字段的使用和解释方式——显然是在有人意识到该字段的使用方式不符合旧 RFC 时起草的（简而言之，ID 被回收得太快了）。

Tyan SMDC 上的 TCP/IP 协议栈非常简陋，似乎把收到的报文当作发送报文的模板。因此，从 SMDC 的角度来看，收发报文拥有 相同的 ID。然而，发送的报文 没有 标记为 Do Not Fragment，这可能 潜在地 引发问题。实际上它基本上保证不会被分片，但这可能会让 Intel Windows 驱动中的 UDP 校验和卸载功能感到困惑，而该功能对分片非常敏感。

既然我无法修复 Windows 驱动，关闭 IPv4 UDP Rx 校验和卸载 对我来说是一个完全可行的解决方案。只不过我本不该需要这么做……