I recently encountered TCP Chimney for the first time in the wild.
Short version: Chimney is an offload technology that allows the NIC to deal with up to X TCP connections, with any overflow being handled by Windows. All good: get the NIC dealing with more networky stuff, and reduce CPU use. Excellent!
The reason it came up:
I was staring at a small network monitor capture (should have been much bigger) that should have had a few tens of megabytes of FTP but was mostly comprised of SYN, SYN-ACK, ACK s to port 21.
A lot! It’d look like
SYN -> 21, source port X
SYN -> 21, source port X+1
…Hundreds and hundreds of TCP 3-way handshakes, but next to no actual data sent. The server didn’t even appear to be sending its connection banner!
Very, very rarely, I’d actually see a frame or two of FTP traffic, but I thought the symptom I was looking at was indicative of resource starvation on the FTP server.
Perfmon didn’t confirm the diagnosis, and the FTP server logs showed it was transferring loads and loads of data; I just couldn’t see it in the capture.
After ruling out network adapter teaming (The Old Enemy), I wondered if something from the Scalable Networking Pack might have been involved, and a quick internal search later, whop! A symptom match! Because the NIC handles the heavy lifting of all TCP work with Chimney enabled, after the TCP session is established, Netmon doesn’t get to see the traffic!
To disable Chimney so you’re able to gather captures for troubleshooting purposes, you can use the following netsh command:
Netsh int ip set chimney DISABLED
Once that’s done, Netmon (and presumably other NDIS capture drivers, like WinPCap (ethereal/wireshark) should be able to capture all traffic, not just non-TCP stuff!