Investigating TCP Checksum Issues With Wireshark

 Protocol analysis is an ever changing art because of 2 significant variables:

Protocols

• Every time an application gets an update it might affect the way it interacts with protocols.

• Operating system upgrades may change the actual protocols or drivers.

• Certain applications might come with its own ‘built in protocols’

Tools

• Every protocol analyzer will have its own different GUI, protocol dissector or decoder and presentation

• Even when you think you got the hang of the tool, that vendor may decide it’s time for an upgrade which may remove, add or break some significant features

In this example I will focus on Wireshark and TCP checksum issues.

Quick review a checksum is calculated and included by the sender of the data. The receiver performs the same math, using the same formula and should get the same checksum value. If this is not the case the receiver ‘may’ decide to discard that packet. I say may because the behavior is based entirely on the vendor and specific protocol in question.

When it comes to TCP I have seen scenarios where a bad driver miscalculates the checksum and the received discarded it. In most cases the receiver will discard the packet if there is a TCP checksum issue.

This is the important bit, if you see TCP checksum errors, take a moment and verify if the corrupted packets have responses, with no retransmissions or large delta times. If that is the case, then the packets are not truly corrupted.

Depending where Wireshark/npcap captured the packet, it is entirely possible that the checksum was not calculated when it was captured. In some cases TCP checksum is enabled on the card which creates the same symptom.

This is yet another reason why I prefer to capture packets after it has left the device.

How TCP Works - Duplicate Acknowledgments (chris greer)

 You don't have to look far in a Wireshark trace file to find duplicate acknowledgments. This common feature of TCP is an often-misunderstood feature of how the protocol ensures reliable delivery of data from one endpoint to another. 

However, when should it worry me? Why do I sometimes see hundreds of duplicate acknowlegments, while in other cases I only see a few? We will dig into those questions and much more in this video. Make sure to download the sample trace file so you can follow along! 

Moving Beyond Ping for Troubleshooting Connectivity

 In the following weeks, our sponsor NetAlly will be sharing some tips that will help you troubleshoot your network faster. This first tip shows us how to move beyond a basic ping when connectivity is a problem.

------

Ask any network pro about which command line tool they use the most – likely ping is near the top of the list, which makes sense. Ping has stood the test of time as a quick way to validate the network path between two endpoints.

But what if it fails? What can we do next?

When a ping is successful, we quickly can validate for at least that moment, we have a working path to the target station, routing is working, and basic connectivity is established. However, it is possible to have a successful ping even when underlying layer one and two issues are there - as these problems may not impact every single frame that traverses them.

Ping response times can also provide some level of understanding of latency across a network.

However, when a ping fails, there can be a host of reasons why. It could be that routing between the endpoints had a temporary failure, a link went offline (perhaps due to an intermittent cabling fault), or that ICMP was blocked by an infrastructure device or by the end station.

So before jumping to conclusions and assuming that the network is having a problem when we see a failed result, there are some additional steps we can take to get more information:

1. Try to validate the connection using a TCP connection

For example, if a web server cannot be pinged, try connecting to it using TCP port 443. This would help to determine if ICMP is being blocked along the path somewhere. This can be done using the telnet tool from most operating systems. However, rather than using the default TCP port of 23, we can use telnet to test connections to a defined port – like 80 (HTTP) or 443 (HTTPS).

2. TraceRoute to the target device/service

If possible, use a non-ICMP trace route tool to validate the network along the way, in case the network is blocking echo requests or other ICMP messages. The MacOS and Linux traceroute tools do this natively, using UDP to test the path. Windows systems use ICMP natively for this tool, so consider this if a device is blocking this protocol and the test fails.

3. Graph ping response times to watch for trends

This can help to determine if a drift in latency is due to intermittent network congestion at certain periods of the day. Taking a persistent ping measurement throughout the day and graphing the results can help watch for latency drifts, which can impact application performance.

Telnet and TraceRoute can be run natively from most operating systems. However graphing ping response times usually requires a little help from another tool.

One way to do it is with the Ping/TCP tool in the EtherScope nXG from NetAlly. This feature allows us to validate the network connection with a ping, check connectivity to a port with the TCP tool, and graph the results over time so we can see trends and drifts. After running these tests, the EtherScope can upload the test to Link-Live for reporting and documentation, which saves the time in creating our own local report.

So, let’s move beyond using just a basic ping to testing TCP connectivity, traceroute, and response time graphing. Together, these help us to more quickly diagnose performance and connectivity issues on the network.