Wireshark Errors - Or Are They?

Red flags aren't always cause for concern

One of the features of Wireshark that you may have noticed, if you’ve been reading my posts this week and doing some experimenting on your own, is that the program color-codes packets in the packet list pane. For example, if Wireshark detects potential problems, it colors them with red text on a black field. Don’t be too concerned if you see some packets that appear this way – it might indicate a problem, but then again it might not. One example of a possible “non-error error” is when you see a lot of “TCP CHECKSUM INCORRECT” messages during a file copy operation. If you’re using reasonably modern hardware, what’s probably happening is that your operating system is offloading the checksum calculation to the NIC hardware, which can do it faster and with less strain on your CPU. Because Wireshark captures outbound packets before they actually get to the hardware, it doesn’t see that the NIC is applying the correct TCP checksums, and so it flags an error. You can tell Wireshark not to worry about this error message by navigating to the Edit menu, choosing Preferences, expanding Protocols, clicking TCP, and clearing the checkbox “Validate the TCP Checksum if possible.” Another message that you might see occasionally is “TCP DUP ACK” (short for “duplicate acknowledgment”). A little research with a good book on TCP could raise a concern that you’re experiencing lost packets, but that may not be what’s happening. This message lets the sender know that the receiver got a packet out of order. But that can happen sometimes and isn’t necessarily indicative of trouble. If you get a lot of packets out of order at one time, say three or four in a row, then it could be that there is a problem, in which case you can move your capture point further upstream to see if the DUP ACK messages disappear at some point. But seeing this message occasionally is normally not a cause for concern. One of the messages that usually *does* indicate some kind of problem is the “TCP ZEROWINDOW” message. TCP has a receive buffer where incoming data is stored until an application grabs it. If this receive buffer fills up, you’ll get the zero window condition, which is fairly serious as it causes the sender to stop transmitting, resulting in delays of potentially several seconds. So, not all Wireshark red-on-black packets are equally worrisome. Kind of reminds you of the Windows event logs, doesn’t it?

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Must read: 10 new UI features coming to Windows 10