CloudShark Blog

Training, webinars, and resources for network analysis

Packet Capture Challenge #2 - Solution

April 3, 2012

This challenge is over for now! Stay tuned for the next packet capture challenge!

First off, thanks to everyone who sent in a solution. Joe shows us the solution on Youtube, or try the challenge yourself below!

The Challange

We are having another Packet Capture Challenge to celebrate the release of CloudShark 1.4. If you can answer the question below, send an email to with your address and Tee-Shirt size, we’ll send out a CloudShark tee shirt to the first 10 correct responses we receive.

This challenge involves a packet capture taken during a session. How works is actually very interesting. The upload and download bandwidth reported are not simply the maximum bytes per second achieved at any point. If you want to go deeper into how some of these bandwidth tests actually work, take a look at the paper “Understanding broadband speed measurements” from MIT.

On to the Challenge

Visit the CloudShark capture session below. During this capture, a speed test is started on IPv4 host The test starts with with the download speed portion and then moves on to the upload portion. The capture session is approximately 36 seconds long. At some point during the capture session, the amount of bandwidth used in the upload direction becomes greater than the bandwidth used in the download direction. Using a round number of seconds like 1, 2, etc, what is that point in time? Hint: Try using the new CloudShark Graphs to explore the capture session.

The Solution

The solution to this challenge is found by visualizing the capture file using CloudShark graphs. However, before we visualize the data, we need to understand what to see. If we look at the conversations view for this capture, we see that almost 10MB of data is exchanged between and This is our bandwidth test.

Now we can create a CloudShark graph and view the download and upload traffic. Since the speednet test is running on, packets with a destination address of and source address of are considered “download” traffic. The reverse is also true. Packets with a destination address of and source address of are considered “upload” traffic.

Now, lets create a bandwidth graph and use these addresses as filters.

We can enter display filters when creating a graph and change the label using the { label } notation.

ip.dst == and ip.src == { Download } ip.dst == and ip.src == { Upload }

We’ve saved the graph as speedtest-net so you can view it below. Select the “Open in Editor” option to see the actual display filters and try customizing it further.

Using this CloudShark graph, you can see that around 17 seconds, the upload traffic kicks in and becomes greater than the download bandwidth. The display time interval also has a big impact on what you see. We used a resolution of 1 second. However, if you use a smaller display time, you’ll see a higher resolution graph and can see the exact time the download portion stops and the upload portion begins.

Until next time!

About Us

CloudShark is made by QA Cafe, a technology company based in Portsmouth, NH. Our passion for packet captures has grown out of our other product CDRouter.

Get in touch via our Contact us page or by following us on your favorite service: