Packet Analysis Challenge #2 – Solution

birds-209280_1920

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:

ws_chal2_q1

#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:

ws_chal2_q2_1

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:

ws_chal2_q2_2

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.

ws_chal2_q3

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.

ws_chal2_q4

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:

ws_chal2_q4_b

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.

ws_chal2_q5_2

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.