While we wait for Magnus Karlsen to make his first move (E4?), here’s a solution walk-through of the second Packet Capture Analysis challenge.

Spoilers ahead

Here we go

#1 – How many hops can we assume there are between the client and the server?

If we assume a default minimum IP datagram TTL of 64 (WHAT? See https://tools.ietf.org/html/rfc1700#page-64), the server 204.152.184.134 is 14 hops away because the IP datagram TTL is 50 in all TCP segments received by the client.

hops = def.ttl – rcv.ttl

How to find the IP TTL value:

#2 – Using fingerprinting techniques, what OS is the server likely running? (1 point per technique)

One way is to look at the HTTP 200 OK response from the server. Usually the application give away some hints on OS and software used:

It claims to be a FreeBSD host.

Another indicator of OS type/version can be found by looking at the advertised IP TTL and TCP Window Size values:

A combination of IP TTL 64 and Window Size 65535 is often found in *nix/FreeBSD systems. More information here and here.

But wait, the Windows client is using the exact same values!? Yes, implementation “standards” are nice

#3 – What is the average RTT delay between the client and the server? (1 point)

Start off by changing View > Time Display Format to Time Since Previous Displayed Packet.

Then we can look at the SYN/ACK response during a TCP handshake to determine the RTT, around 20 ms in this case.

Why the SYN/ACK handshake step? Because that segment is generated by the remote end TCP/IP stack, without any added application delay.

#4 – Following frame #14886, what TCP sequence number (relative) is the client expecting to receive next? (1 point + 1 bonus)

Looking at frame #14886 we see a TCP sequence number of 4641056. That segment had a payload of 1460 Bytes. The next sequence number in the stream is 4641056 + 1460 = 4642516.

As we see in frame #14889 the client does not receive the expected segment and TCP SACK kicks in.

Bonus – In what frame does it receive the expected TCP segment?

Since we know that the sequence number is 4642516, we can apply a specific Display Filter using tcp.seq:

Frame #14981!

5# – At the beginning of the file transfer there is a delay lasting around 3 seconds. Why? (2 points)

A graphical representation of the transfer halting
Statistics > TCP Stream Graphs > Time Sequence (Stevens):

Awkward silence.

The client TCP receive buffer is considered full in frame #8662. The client is reporting a window size of 536 Bytes which does not allow for a full TCP segment of 1460 Bytes. For some reason the client application (browser) is not pulling data fast enough from its buffer.

The transfer halts for around 3 seconds until the client has finished processing the data and reports a window of 64 KB (256KB as seen in Wireshark is due to Window Scaling). The server continues transferring at frame #8665.

That’s it!

Hope you had some fun solving these. More to come

Have a nice day! 

The Sharkminator returns.

Round two of #Wiresharklympics is here! Having survived round one, you know the drill. The tiny specs of data that allow services like Facebook and the Internet to work will be put under heavy scrutiny.

Wireshark has reached a stable release of 2.2.1 and is eagerly awaiting new challenges.

We will yet again use a sample packet capture from Netresecs list.

The packet capture sample can be downloaded here:
https://dl.dropboxusercontent.com/u/1185688/blog/wireshark2.pcapng

It’s safe to download. VirusTotal concur.

Enough yada yada

Five questions. Should be at least 8 points up for grabs

Start off by applying this display filter “tcp.stream == 16”.

1. How many hops can we assume there are between the client and the server? (1 point)
2. Using fingerprinting techniques, what OS is the server likely running? (1 point per technique)
3. What is the average RTT delay between the client and the server? (1 point)
4. Following frame #14886, what TCP sequence number (relative) is the client expecting to receive next? (1 point + 1 bonus)
   Bonus – In what frame does it receive the expected TCP segment?
5. At the beginning of the file transfer there is a delay lasting around 3 seconds. Why? (2 points)

Easy peasy?

Please send me your questions and answers via a communication transport of your liking. A comment here, the social medias or email. Doesn’t matter!

The winner will of course receive loads of street cred. Way better than Facebook likes.

Have a great day

The Sharkminator

Vacation’s over. Your networks have been underutilized for a good long month now. Time to get back to the trenches. Why not start things off with a proper packet analysis challenge? At least fire up Wireshark to see if there’s an auto-update waiting for you?

Thank you Netresec for providing a huge list of packet captures to play with!

We will borrow a 13 MB packet capture from the excellent book “Practical Packet Analysis“.

$ shasum wireshark1.pcapng
b8060f2b946f33b79833710db458368cd382d06c wireshark1.pcapng

Please go ahead and download the pcap file. Yes, it’s safe to download.

Ready?

<gong sound>

Five questions + one bonus. One point per question:

1. How many non-broadcast IPv4 nodes is Wireshark seeing?
2. The client downloads an EXE file, twice. From which countries is it downloading the file from?
3. How many Bytes is the client expecting to download for each EXE file?
4. Looking at the fastest of the two transfers, at what speed is the file downloaded on average in kbps, kilobit per second?
5. One node is not accepting the use of full TCP segments. Which one?
   1. BONUS – How many Bytes is the client potentially missing out on per round-trip?

Easy peasy?

Please send me your answers via a communication platform of your liking. The social medias or email. Doesn’t matter!

The winner will get loads of street cred as defined by Urban Dictionary:

He’s been thru it all. His street cred is undeniable.

That’s all you need. Get to it!