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, behavior or drivers.  

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

Tools 

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

Even when you think you got the hang of the tool, that vendor may decide to remove, add or break some significant features with its latest upgrade. 

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 driver miscalculated the checksum and the receiver 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 and sent. 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.

---

#netscout

Salt Typhoon didn't succeed because they were noisy. They succeeded because they were difficult to distinguish from normal activity.

How TCP Works - Duplicate Acknowledgments (Chris Greer)

Unlock the Mystery of Duplicate Acknowledgments in TCP

If you've ever stared at a Wireshark capture wondering why you're seeing a flood of duplicate acknowledgments, this video by networking expert Chris Greer is exactly what you need. In this focused, no-fluff tutorial, Chris breaks down one of the most commonly misunderstood behaviors in TCP/IP traffic analysis — duplicate ACKs — and explains not just what they are, but why they appear and what they're telling you about your network.

Perfect for Troubleshooters at Every Level

Whether you're a seasoned network engineer or just getting started with packet analysis, Chris has a knack for making complex TCP mechanics approachable and digestible. He walks you through real trace files in Wireshark, showing you how to identify duplicate acknowledgments, read them correctly, and understand the conditions under which you might see hundreds of them pile up in a single capture. It's hands-on learning at its best.

Learn by Doing with a Real PCAP File

One of the standout features of this tutorial is that Chris provides a downloadable PCAP file via CloudShark, so you can follow along in your own Wireshark environment as you watch. There's no better way to build confidence with packet analysis than working through a real capture side by side with an expert guide — and this video gives you exactly that opportunity.

Part of a World-Class Wireshark Learning Library

This video is just one gem in Chris Greer's extensive catalog of Wireshark and TCP/IP training content. As the founder of Packet Pioneer and a trainer with thousands of students worldwide, Chris brings both deep technical knowledge and genuine teaching ability to every video. If this tutorial sparks your interest, he also offers full courses on Wireshark and Nmap, as well as live virtual TCP/IP deep-dive sessions for those who want to go even further. Subscribe to his channel and level up your network analysis skills today.

---

#netbeeze 3 Strategies for Effective Remote Network Monitoring

Moving Beyond Ping for Troubleshooting Connectivity

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.

The Canonical Weekend - Paul Smith

 

A former boss of mine had a well-rehearsed response for any employee who complained they had too much work. There are twenty-one 8-hr workdays in a week, he would say; three in each of the seven 24-hour days. If you are only using five out of those twenty-one, you are clearly just lazy.

Although the 40-hour workweek would be a dream come true for many (unless you happen to live in Luxembourg) , there are few among us who could ever envision working the 168 hours suggested by this guy. The average full time US worker puts in 41.5 hours, making us a nation of slackers by my old boss’s standards. The hardest workers are found in Colombia, where the average work week is nearly 50 hours, still less than a 30% utilization of available time. 

Troubleshooting At The Physical Level

I thought it would be a good idea to start a series using the NetworkDataPedia’s theme of ‘knowing your network. 

Let’s start at layer 1 or the hardware layer.

Unfortunately, there is so much that can go wrong at this layer that I cant possibly cover it in one article.  I see a lot "you have a network connection and life will seem fine" attitude. This is unfortunate because if the problems would cause an complete outage, you would be forced to address it instead of ignoring it.

I find that many physical level issues are grouped into a few categories:

Installation and Support