Tuesday, August 18, 2020

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.



Friday, August 14, 2020

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! 



Tuesday, August 4, 2020

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.


Monday, July 20, 2020

The Canonical Weekend

 

The Canonical Weekend

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. 

Like many averages, these numbers hide deeper truths. There are those who work several jobs in order to make ends meet and others whose employers limit their hours in order to avoid paying overtime. Much of the available data is based on self-reported hours, and who doesn’t think they work longer and harder than they actually do? 

The very definition of work leaves a bit of wiggle room as well. The dictionary explains “work” as activity requiring effort to achieve a purpose, adding that it is something a person “has to do.” Our culture generally views work as something we are glad to be done with, hence the evolution of “Happy Hour” (for the consumption of adult beverages at the end of a workday), “Hump Day” (for the work week’s midpoint) and “Thank God It’s Friday – TGIF” (for the eagerly awaited end). All of this leads up to the weekend, commencing a two-day respite from having to do things requiring effort to achieve someone else’s purpose.

Most of us have never questioned the existence of weekends, having been trained since childhood to accept this ordering of our days. One company I worked for had a schedule of four nine-hour days, followed by a four-hour day that ended ostensibly at noon. The 2 ½ day weekend was much appreciated by those of us who could break away on Friday. Another popular variant is the 9/80 system, which effectively offers alternating 3- and 2-day weekends. I am sure there are other ways to carve up a seven-day block, but the basic idea of large chunks of work, interspersed with a smaller ones of time off, remains sacrosanct.

History reveals that we have not always had weekends. Primitive hunter-gatherers are unlikely to have had any days off, given that they were self-employed without benefits, unions or OSHA. We know enough about the early Romans to recognize that the week was not even a unit of time in their calendar. Months were apparently a thing in ancient Rome, but rather than numbering the days, they ordered them by their distance from various lunar phases. A farmer’s market was held every eighth day, but there is no indication of a day set aside for rest.

Records show that the Romans did schedule numerous fariae publicae, or public holidays, when politics and legal business were put on hold. These, along with numerous one-off holidays proclaimed by various consuls, may have been taken as an excuse to skip work. Still, life was ordered according to the earth’s trip around the sun and the lunar cycle.  

When Emperor Constantine converted to Christianity in 321 AD, he formalized the Biblical seven-day week, with Sunday devoted exclusively to worship for all but the farmers. Centuries later, Victorian factory owners began to add Saturday afternoons off for their employees, eventually leading to the two-day weekend as we know it today. 

Years and months remain driven by the Sun and Moon and thus hard to change (until we colonize Mars) but seven-day weeks are basically a 1,700-year-old human invention. While the weekend as we know it has been in place for well over a century, a lot has changed and perhaps revisiting our allocation of time is not such a bad idea.

British Labour Party leader Jeremy Corbyn has no problem with the seven-day week but would like to see the work/play ratio changed from 5/2 to 4/3. Academics who feel we are working much too hard have suggested changing to an eight-day week, with three-day weekends (5/3). Upon closer scrutiny, Corbyn’s proposal would eliminate “Hump Day”, a loss our culture may be unwilling to accept.

From time to time, history throws us an unexpected change-up (say, for example, a global pandemic) giving rise to another oxymoronic “new normal.” Many of our typical reference points based on daily routines are suddenly gone. Meeting friends for Happy Hour, watching Monday night football, and dressing differently on workdays versus days off no longer provide the framework we are accustomed to. The ordering of our days has a profound effect on our lives, and psychologists worry about the mental health impact of disrupting that order. 

Disrupted it is, and now is the perfect opportunity to revisit the centuries-old division of time and try something new. The 8-day week with 3 days off may very well be a better fit for today’s culture. The extra day could be named “Pasiday” (after Pasithea, the Greek god of leisure).  As an added bonus,  the scholarly 8-day week would have 24 working days. Just imagine what we could accomplish with those 192 hours...

Author Profile - Paul W. Smith - leader, educator, technologist, writer - has a lifelong interest in the countless ways that technology changes the course of our journey through life. In addition to being a regular contributor to NetWorkDataPedia, he maintains the website Technology for the Journey and occasionally writes for Blogcritics. Paul has over 40 years of experience in research and advanced development for companies ranging from small startups to industry leaders. His other passion is teaching - he is a former Adjunct Professor of Mechanical Engineering at the Colorado School of Mines. Paul holds a doctorate in Applied Mechanics from the California Institute of Technology, as well as Bachelor’s and Master’s Degrees in Mechanical Engineering from the University of California, Santa Barbara.

Popular post