318 posts categorized "Protocol Analysis" Feed

Wireshark Week - Troubleshooting Performance in the Cloud (by Paul Offord)

While the decision to move to the cloud rarely involves them, supporting end-user issues often falls to the network team. Migrating an application to a Virtual Private Cloud (VPC) could leave engineers in the dark, lacking visibility and insight to diagnose and resolve user issues. The good news is that with a bit of planning and some lateral thinking, we can still use packets to see into the cloud.



There are two main factors affecting our ability to analyse network traffic in a cloud environment.  The first is component location:

  • Single Cloud - all components are hosted in a single VPC
  • Multicloud - where application components are hosted by more than one cloud provider
  • Hybrid - where some application components are retained onsite

The second complicating factor is the type of hosting or platform service used.  These service types become progressively more abstract.  Using Amazon Web Service (AWS) offerings as an illustration:

  • EC2 i3.metal - a bare metal server offering for customers with particular needs
  • EC2 - a virtual machine running Linux or Windows
  • Fargate - a managed Docker container service
  • Elastic Beanstalk - a managed application server
  • Lambda - serverless code execution

As we progress down the list we get further away from the underlying infrastructure.  The situation is further complicated because as we move down this list there is a big increase in the dynamic nature of the application execution.  Docker containers will start …

Continue reading "Wireshark Week - Troubleshooting Performance in the Cloud (by Paul Offord)" »

How TCP Works – The Timestamp Option (by Chris Greer)

TCP Timestamp TSval TSecr

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.

TCP Timestamps

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

Continue reading "How TCP Works – The Timestamp Option (by Chris Greer)" »

Diffusing The IT Blame Game With Network Visibility (by Keith Bromley)

Diffusing The IT Blame Game With Network Visibility

How well does your company communicate internally? Specifically, how well do your IT departments communicate with each other?  Enterprises typically contain four or more IT sub departments (Security, Network Operations, Virtual DC, Capacity Planning, Service Desk, Compliance, etc.) and it’s quite common for them to be at odds with each other, even in good times. For instance, there’s often contention over capital budgets, sharing resources, and headcount.

But let’s be generous. Let’s say that in normal operations things are usually good between departments. What happens if there’s a breach though, even a minor one? Then things can change quickly. Especially if there are problems with acquiring accurate monitoring data for security and troubleshooting areas. Finger pointing can quickly result.

So, what can you do? We recently discussed this on an LMTV podcast How To Diffuse The IT Blame Game. One of the answers is to create complete network visibility for network security and network monitoring and troubleshooting activities.

For instance, here are three common sources of issues for most IT organizations:

  • There is a lack of proper access to network data
  • Analytic and security tools can be modified, moved, or just plain disappear without permission
  • Capture and analysis of monitoring data can create business risk and problems for other departments

Continue reading "Diffusing The IT Blame Game With Network Visibility (by Keith Bromley)" »

Troubleshooting a Cloud Problem with Wireshark (by Paul Offord)

The slowly growing interest in Cloud Computing that started ten or so years ago is turning into a stampede.  Most of our customers at Advance7 have strategic plans to migrate many systems to a cloud platform, and many have already started the journey.

Cloud application topology

In fact, we too have migrated all of our systems into AWS and Azure, containerising many of them in the process. But here's a concern we shared with our customers:

"Will we have enough visibility to troubleshoot performance and stability problems once we have migrated our systems?"

It's a good question.  We don't want to discover that the whole environment is opaque, just when we need to troubleshoot a serious problem.  We satisfied ourselves that we could get the data we needed to maintain our systems.  We found that we could get a lot of information from the Application Load Balancers, and we configured continuous packet captures to record traffic between the tiers of our systems.  Just as well as a couple of months ago we hit a performance problem with the TribeLab Community website.

I managed to record the actions of our Performance & Stability Engineers as they used AWS CloudWatch and Wireshark to investigate the problem.  I pulled together screenshots, video clips and other information to produce a short video case study …

Continue reading "Troubleshooting a Cloud Problem with Wireshark (by Paul Offord)" »

IoT: Tesla Model S Remote Control (by Jonathan Whiteside, Darrin Roach and Paul Offord)

With the proliferation and expansion of wireless technologies, it is now becoming commonplace for vehicles to be connected to the Internet for numerous reasons, such as website access, telematics and always connected emergency services.

Tesla Motors is very much at the forefront of the ‘Connected Vehicle’ revolution, producing vehicles with ‘always on’ connectivity through 4G LTE and WiFi.  This gives the driver features such as Google Maps navigation, web access and Spotify.


It also allows remote operation features such as climate control and charge port opening/closing, as well as providing an instant view of battery charge levels.  All these features can be readily accessed from a mobile phone app or desktop app on a PC.

The objective of this experiment was ...

Continue reading "IoT: Tesla Model S Remote Control (by Jonathan Whiteside, Darrin Roach and Paul Offord)" »