The Highlighted Route

 

It is in our nature as humans to plan. Some of us do it formally, writing down step by step instructions with a well-defined goal in mind. Others plan at a smaller scale, often thinking about step 2 after step 1 is underway. If you are out doing errands, advanced planning can save time with a more efficient route. If you are doing a project, planning can help avoid painting yourself into a corner (literally). When it comes to travel, planning might include packing things you will need or putting a hold on the mail, but it most definitely will involve some sort of pre-determined route. Airline pilots do this sort of route planning routinely to conserve fuel, avoid bad weather, and arrive at their destination on time. They submit a formal flight plan to document their intentions.

Pilots have their own lingo, helping to ensure clear radio communications. A typical flight will likely involve VFR, IFR and VOR and most certainly will be highly dependent on ATC. One acronym to be avoided at all costs is CFIT (controlled flight into terrain), which is just as bad as it sounds. If you know your precise location and altitude, CFIT is unlikely, even if IFR conditions are making it impossible to see anything out the window. This is where GPS comes in. 

Beginning with the DoD NAVSTAR satellite-based system in 1993, GPS developed into a sophisticated positioning system that is highly accurate, easily accessed and substantially free of charge. It is operated by the Air Force for the US Government to meet the needs of military, civil, commercial, and scientific users. Coarse position codes are open to everyone, while the more accurate ones are restricted to the US Armed Forces and Federal Agencies. That GPS in your car can get you to within about 10 feet of your destination and if you can’t recognize it by then there’s not much more technology can do for you. As for the military version, let’s just say it is much more accurate and leave it at that.

In a peculiar bit of irony, the U.S. Military occasionally jams its own GPS signals in order to research ways to keep them from being jammed. Imagine piloting a modern jetliner with a hundred or more people on board when a warning suddenly pops up in the cockpit – “GPS Position Lost.” Although pilots have altimeters and VOR beacons for navigation, GPS made the entire point-to-point flying experience much more efficient. Most planes carry transponders which use the GPS for broadcasting altitude, heading and speed to controllers on the ground. While GPS works flawlessly 99.9% of the time, it’s a challenge to stay ready to respond to that other 0.1%.

Perhaps even more concerning is the case where GPS doesn’t just go away but starts returning erroneous data. GPS signals are so faint by the time they reach us that it is relatively easy to disrupt them, and illegal jamming devices are widely available on the black market. A delivery driver who doesn’t want his boss to know where he is can easily avoid being tracked. Intermittent GPS could be due to natural factors, jamming, or a government test – there is often no way to know. 

It's hard to miss the similarities between GPS's highlighted route, and the paths we lay out for other parts of our lives. We like to believe that we know where we are relative to our goal at any given moment.  Some of us believe there is a Master Plan for our life that will guide us to fulfilling a divine purpose. Some are intimidated by the unknown and take comfort in staying on a highlighted route, at times provided by others, with frequent detailed guidance and no surprises. Weak signals, jamming, and system failure are an inevitable part of life.

I realize in retrospect that my parents had planned a route for me when I was in High School. I weathered a few detours and course corrections along the way, but I did ultimately arrive at my destination. In some of those moments of “position lost”, I felt a potent mix of fear and infinite possibility. From time to time, friends and family stepped in and reminded me to return to the highlighted route. 

And unlike a few of my less fortunate peers, I managed to avoid CFIT.

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.

Automating Packet Analysis with Sharkd and Python

 Have you ever had one of those days when your packet analysis seems doomed?  We start looking and quickly realise that there are duplicates of all the packets in one direction.  So we process the file with your favourite de-dup tool and try again.  Next we find some packets were dropped during capture.   Hopefully, we have enough.  Hang on, where's the traffic to the server?  Things are going from bad to worse and we are already 2 hours in.

If only we could check the data before breaking out Wireshark.

This video explains how to use Sharkd and its API to automate the analysis of network packet data. I go on to demonstrate the capability using an experimental Python program to check the quality of a packet capture file. We close the video with details about Sharkd installation and documentation.

The modified sharkd_session.c code I used is here - https://gitlab.com/credible58/wireshark/-/tree/issue17235

The Python program used in the video is here - https://github.com/credible58/papr/tree/main

Replay: How TCP Works - The Timestamp Option (by Chris Greer)

 

In the TCP handshake, you may see an option called timestamps, shortly followed by scary-looking “TSval” and "TSecr" numbers. What are those values and how can you interpret them? Let’s dig.

What is a TCP Timestamp?

The timestamps option in TCP enables the endpoints to keep a current measurement of the roundtrip time (RTT) of the network between them. This value helps each TCP stack to set and adjust its retransmission timer. There are other benefits, but RTT measurement is the major one.

How it works.

Each end of the connection derives a 4-byte increasing value. This value is unique to each side and has no real numerical significance. The opposite end does not care what the value is, it will simply echo it back to the original sender. The original sender can then measure the timing between the packet(s) that were sent and received with this unique value.

The value used by each end will be increased as the connection goes along. Many TCP implementations will add the measured network RTT value (in milliseconds) to the 4-byte timestamp and use this new number for the next segment to be sent.

For example, in the screenshot below, we can see both ends of the TCP connection using timestamps. Both values, the one used by the sender and receiver, have been added as columns in Wireshark to make them a little easier to see.

The first packet has a timestamp value of 1125169296. Told you it was long and scary! But let's analyze...

At the start of the connection, the sender has not yet seen a timestamp value from the opposite end of the connection, so it has no number to echo back yet. That is why we see a zero in the Timestamp Echo Reply column.

The second packet shows the receiver echoing back the timestamp value, while sending a unique value of its own. Notice that these two numbers are completely different and are not related to each other at all. However, in the SYN/ACK, the timestamp echo value must be exactly the same as the value sent in the SYN, or the connection will fail. The connection initiator will likely send a reset to clear the connection.

Next, in the third packet, we can see that the original sender increases its timestamp by 212, sending a new value to the other end. From the delta time column, we can see that the roundtrip time between the two stations is 212 milliseconds (we captured on the 192.168.10.108 end). This value is added to the original timestamp and sent out on the next segment.

As the connection goes along, these values will increase. While they look long and scary, remember that they are only echoed back from the opposite side allowing the sender to mark and measure the roundtrip time. The value itself doesn’t have a specific meaning.

Keep in mind that the TCP Timestamps Option and the Wireshark-derived TCP Conversation Timestamps (which you need to enable in Wireshark) are very different things. For some info on the conversation timestamps, check out this video:

Getting Started Is The Tough Part

 Regardless if you are troubleshooting, baselining installing or designing getting accurate data is critical.

We’ve all heard that old saying “garbage in, garbage out” but what about “no data, no chance”?

When I present or teach I always try to instill some basic concepts to help attendees regardless of their role.

The first point is “get off your chair”. When possible get off your chair and visit the site, or client, to get a proper perspective of the issue, site and gather first-hand information. In the day of video calling, and the ability to record video/photos from your phone, you can ask the client to ‘show you the issue’ or a walk around the site.

The second point is to document! Document anything, tools used, methodology the switch make/model, ip addresses, port numbers, operating systems, etc… you would be surprised how helpful this information can be for you at a later date or for someone else working with you.

No matter what you do, document or start with, just start with something. For example, I get many requests to help with application or device baselines. The first thing I ask is how do you want to baseline? There are many options; you can use the SNMP port stats of your switch to watch load/utilization, review firewall logs for port numbers used, if its windows or linux, look at netstat output, or lastly capture packets.

When I started working with packet analyzers, I would capture packets while on hold or any opportunity so I can get comfortable with the tool and interpreting the results BEFORE I take it out in the field.

The critical part of performing packet captures is to ensure you note if you used a span port, hub, tap, directly from the device to capture your packets. The most common techniques I see out there is a span port or tap.

When it comes to taps, they are not all built the same, or have the same features. Make sure you get the one that fits your needs, for example is it a packet broker, goes it pass POE through, what interface does it use to connect to your computer, how user friendly is the software, etc..

In this short video, I show you how I connected a Profitap Profishark inline to capture a phone’s bootup for baselining, troubleshooting and baselining.

Cheers