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 126.96.36.199 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:
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:
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):
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.
Hope you had some fun solving these. More to come 🙂
Have a nice day! 🖖