Packet Analysis Challenge #1 – Solution

It’s time for a walk-through of how to solve the first Packet Analysis Challenge.

Happy to see that there are plenty of fine Wireshark warriors out there! Hope you had some fun 👍

The fastest one to answer all the questions including the bonus round was a local champion named Martin Karlsen! Lots of packet level street cred is hereby sent your way. He also has a website up at exceededintransit.net that you can check out. Don’t expect to find cooking recipes there. Next-gen Jedi that one.

Yes, OK, just give me the answers

#1 – How many non-broadcast IPv4 nodes is Wireshark seeing?

Go to Statistics > Endpoints to list all the endpoints that Wireshark is seeing across all TCP/IP layers. Select IPv4:

With 255.255.255.255 being a Limited Broadcast address (rfc5735#section-4), this leaves us with a total of 11 IPv4 nodes.

 

#2 – The client downloads an EXE file, twice. From which countries is it downloading the file from?

Apply a display filter to only focus on HTTP requests containing the word “exe”:

Frame number 842 and 8292 initiates the downloads and list two different destination IPv4 addresses. Run a whois query against them to find out where they originate:

$ whois 61.8.0.17 | grep Country
Country: AU
$ whois 204.152.184.134 | grep Country
Country: US

There you have it, Australia and the United States.

 

#3 – How many Bytes is the client expecting to download for each EXE file?

We can find this information by looking at the HTTP 200 OK response from the server (frames 844 and 8294):

The HTTP header Content-Length indicates the size of the entity-body in Bytes (rfc2616#section-14.13).

The client therefore expect to download 78597807 Bytes (78.5 MB).

 

#4 – Looking at the fastest of the two transfers, at what speed is the file downloaded on average in kbps, kilobit per second?

Go to Statistics > Conversations and select TCP (since the two transfers used HTTP, which is transported over TCP).

Click on the column Bytes to sort the table. The top two conversations list the file transfers.

Next, find the column Bits/s B -> A (meaning the download direction from the client perspective).

The server providing the fastest file transfer is the US host 204.152.184.134. It delivers the EXE file at an average speed of 2344 Kbps or 2.34 Mbps.

 

#5 – One node is not accepting the use of full TCP segments. Which one?

A 100% fully utilized TCP segment carry 1460 Bytes. You can load the HTML payload of http://ulv.no almost three times in such a segment. Plenty of data.

If there’s a need for a limit, it is set during the initial TCP handshake in a separate TCP header option:

https://tools.ietf.org/html/rfc793#page-19

Maximum Segment Size Option:
If this option is present, then it communicates the maximum receive segment size at the TCP which sends this segment. This field must only be sent in the initial connection request (i.e., in segments with the SYN control bit set). If this option is not used, any segment size is allowed.

Meaning, if Node A set its MSS to 1100 and Node B set its MSS to 1460 in their handshake, any segment sent to Node A must be limited to 1100 Bytes. Node B however is happy to receive up to 1460 Bytes of payload.

So which one is it?

First, apply a display filter to single out all TCP handshakes. All handshakes must have the SYN flag set.

Next select a frame, then in the Packet Details pane, expand the subtree of Transmission Control Protocol. Scroll down to Options and look for Maximum segment size.

Expand it and right-click on MSS Value and select Apply as Column:

This allow us easily see all the TCP MSS values set during TCP handshakes.

By sorting using this new shiny MSS Value column, we find one outlier:

The host 216.251.114.10 in frames 6 and 30 limit any TCP segments sent its way to 1380 Bytes.

Optional solution:
Apply a display filter to list all MSS values below 1460 Bytes using “tcp.options.mss_val < 1460“.

 

BONUS – How many Bytes is the client potentially missing out on per round-trip?

If a full TCP segment is 1460 Bytes, then we’re missing out on 80 Bytes of data in each TCP segment sent towards 216.251.114.10.

But wait a minute, you said client! Hahaa! 👯

Yes I did. And in retrospect it was a weird example to use since 216.251.114.10 is a web server and not a client. Or is it..? This could turn into a nice client-server model debate.

But, because of this ambiguity – my bad. Or as the Urban Dictionary would put it:

“I did something bad, and I recognize that I did something bad, but there is nothing that can be done for it now, and there is technically no reason to apologize for that error, so let’s just assume that I won’t do it again, get over it, and move on with our lives.”

Have a great day! 🐳