Part 1: SYN, FIN, and All That

In this part of the lab, you will use WireShark and netstat to look at several TCP sessions to investigate opening and closing of connections.

Recall that WireShark is used to capture packets. You might need to review Lab 2 if you don't remember how to use it.

Question 1: For this question, start a WireShark capture session, ssh to any of the cslab computers or to math.hws.edu, and log in. Immediately give the "exit" command to log out. Then stop the capture and take a look at the packets. Set the WireShark "Filter" to "tcp.port == 22". Click "Apply". With this filter, you only see packets that use the ssh protocol (port 22 is the standard port for ssh). Describe the packets that are used in the opening three-way handshake and in the closing handshakes? What, if anything, is in the Options section of the SYN and SYNACK TCP packets? How long did the open and close sequences take?

Question 2: After a TCP connection is closed, the partner that initiated the close operation goes into a "TIME_WAIT" state to make sure any left-over packets have left the network. The textbook says can last for 1/2, 1, or 2 minutes, depending on the implementation. I would like you to find out how long it lasts in Linux. To do this, you need a way to observe the state of a TCP connection; the netstat command can serve this purpose. Run netstat with the command

netstat -t -n -c

This will show TCP connections and will repeat the output continuously until it is interrupted with CONTROL-C. Part of the output is the connection state, which can be things like ESTABLISHED, FIN_WAIT2, and TIME_WAIT. I want you to find out how long the TIME_WAIT state persists after you close a connection.

You can use a telnet session to the web server math.hws.edu (port 80) to test this, but you just want to close the connection without sending any data. To do this, use the command

telnet math.hws.edu 80

Then instead of sending any command, you want to force the connection to close from your side. To do that, hit CONTROL-] (control key plus left-bracket). You will get a telnet> prompt from the telnet client on your computer, which means you are talking to the telnet program instead of to the web server. Enter the command close to tell telent to close the connection. You should report on how long the TIME_WAIT state lasts and explain exactly how you determined the answer.

Question 3: Keep netstat running while you do this question. Start up WireShark again, if it's not already running. Use "tcp.port == 23" as the "Filter." (23 is the standard port for telnet, when no other port is specified.) Start the WireShark packet capture session. For this exercise, try to telnet to a non-existent IP address outside the HWS local area network. For example, "telnet 123.45.67.89" should work. Based on the packets displayed in the WireShark capture session, describe what TCP does in this case as it attempts to open a connection. (Give it some time.) Also, what do you see in the output of netstat, and why?

Part 2: TCP in Depth

This part of the lab is vaguely based on the WireShark lab for TCP from our textbook's web site. However, instead of the questions in that lab, I want to ask my own questions (some of which are adapted from the textbook's lab).

Note added late: This part might work better with a larger file.
Try it with /classes/cs441/zipcodes.txt instead of alice.txt?

For this part of the lab, you will use the file /classes/cs441/alice.txt, which is a copy of the book Alice in Wonderland. Actually, any file of one or two hundred kilobytes would work just as well.) You will upload this file to the textbook's Web site using the file upload page at the Web address shown below, but before you click the submit button on the web page, start up WireShark and begin a packet trace.

       http://gaia.cs.umass.edu/wireshark-labs/TCP-wireshark-file1.html

Go to the page, start the WireShark packet trace, and upload the file /classes/cs441/alice.txt. After the file has been successfully retrieved, you can stop the packet trace. You will probably want to save the packet trace, using WireShark's "Save" command. That way, you can revisit the trace later just by loading the file back into Wireshark, instead of having to repeat the experiment.

You only want to look at TCP packets in the packet trace, so once again you should enter "tcp" as a filter in the "Filter" box at the bottom of the WireShark window, and click "Apply". (If you see extra TCP packets that are not part of the conversation with the web server, you might want to use a filter such as "tcp.port == 80" to leave them out of the list.)

Question 4: WireShark, in its default configuration, reports zero-based sequence and ACK numbers. That is, it subtracts the initial sequence number to get a number that represents an actual number of bytes in the data stream. What sequence number does it report in the initial SYN packet? What ACK number does WireShark report in the SYNACK packet? Why? Can you find the actual initial sequence number from the SYN packet? (Hint: You can find it somewhere in the WireShark window, but it will be in hexadecimal format.)

Question 5: Look at the first segment for the HTTP Post data. This is the beginning of the file upload. What is the sequence number in this packet? Why? Look at some of the ACK packets received from the server as the POST message is being sent. What is the value of the sequence number in each of these packets? Why?

Question 6: Explain how you can find the actual round trip time for a given ACK packet, just by looking at the information in the top third of the WireShark window. (Note that the time column specifies the time in seconds since the beginning of the packet trace.) If you look in the TCP section of the ACK packet in the middle third of the WireShark window, you will find that the round trip time has already been calculated for you. Look at the first six ACKs that are received from the server. For each ACK, compute the value of the TCP state variable EstimatedRTT, as given by the formula

          EstimatedRTT = (7/8)*EstimatedRTT + (1/8)*SampleRTT

Do you observe a lot of variation in the measured RTTs over the course of the transmission? (You can use WireShark to get a plot of all the RTTs. Click on any TCP packet, then select the "Round Trip Time Graph" command from the "TCP Stream Graph" sub-menu of the "Statistics" menu.)

Question 7: Is a separate ACK received for each data packet, or did the server sometimes acknowledge several packets with one ACK? Can you find any retransmitted packets? What did you look for to determine the answers?

Question 8: Click on any TCP packet in the conversation, and then select the "Time Sequence Graph (Stevens)" command from the "TCP Stream Graph" sub-menu of the "Statistics" menu. This graph shows the time at which each packet was sent. Describe the pattern of times that you observe. Do you see groups of packets that are sent in "clusters" at almost the same time? If so, what changes do you see in the sizes of these clusters? If not, what do you see? Can you find evidence of TCP's congestion control algorithm -- including the slow start and the congestion-avoidance phases -- in the Time Sequence Graph?

Question 9: The reason for using an upload to a remote site in the previous questions was to get a realistic view of transmission over the Internet. Transmission inside a local area network should be faster and more reliable. Do a packet capture of uploading the file /classes/cs441/alice.txt to the page at http://math.hws.edu/eck/cs441/upload.html. Comment on any differences between this local transfer and the Internet transfer. How much faster is it?