GoKawiilLast week I spent far too much time trying to get my Windows 11 machine to talk to an antique Tyan SMDC (Server Management Daughter Card) IPMI module over the network.
At first, I tried Tyan’s own old TSO (Tyan System Operator) software in a Windows XP VM using NAT networking. The software installed without incident but was not able to discover any IPMI-enabled servers. All my attempts to manually set up communications to the server also failed. I also tried native Windows software (ipmiutil) with effectively identical result — the SMDC would not respond.
Next I tried my old PC running Windows 10. It behaved the same — ipmiutil refused to talk to the SMDC. At this point, I strongly suspected that the SMDC was not set up right, but just to be sure, I rebooted the old system to Linux and tried ipmitool . Lo and behold, ipmitool on Linux could talk to the SMDC! I set up a similar Windows XP virtual machine on the Linux host and guess what, the TSO software worked fine as well.
All my attempts to disable Windows firewalls and such on the Windows hosts made zero difference. In desperation, I ran Wireshark on the Windows 11 system and established that yes, there is outgoing UDP traffic (to port 623 on the SMDC), and what’s more, the machine is in fact receiving replies from the SMDC! But somehow Windows was eating up the incoming UDP packets and software running on the machine never saw anything. That was, to put it mildly, suspicious.
In an attempt to further narrow down the problem, I tested an old laptop running the latest Windows 10. To my surprise, ipmiutil worked just fine. That shot down my working theory that something in recent Windows 10/11 ate the IPMI UDP packets.
On the Windows 11 machine, I ran PktMon in the hope that it would tell me something that Wireshark did not. Bingo, it did. Although PktMon is generally not that different from Wireshark, it tracks how the network traffic flows through the various Windows networking software layers.
In a text log file produced by PktMon, I found an important clue:
DropReason INET: checksum is invalid
The UDP packet was received and moved up from the network interface through a few filter layers, but the Windows TCP/IP stack dropped it due to an invalid checksum. I turned on checksum validation in Wireshark, but Wireshark thought that the IP and UDP checksums in the received packet were just fine. That was even more suspicious.
The only thing left was to start flipping various options in the driver (e1r68x64.sys) for the Windows 11 machine’s NIC, an Intel I211. It didn’t take me long to establish that turning off UDP receive checksum offloading for IPv4 fixed the problem. Suddenly ipmiutil worked, and VMs running on the system started talking to the SMDC as well.
... continue reading