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.

Since you will be using Wireshark, you need to log into your netXX account. After logging in, open a terminal window and enter the command

netstat  -tnc

Recall that netstat -tn will show TCP connections between the computer you are using and other computers. Adding the "c" option to the command will make netstat run continuously, outputing a new list of connections about once per second. It will be interesting to leave the command running as you do this part of the lab, and it will be required for Question 3.

Question 1: For this question, you will look at the opening and closing handshakes for a TCP connection that is used to download a web page. You should open a web browser, if you don't already have one open, and access this page. Start up Wireshark, select the ethernet interface eno1 as usual, and start a capture session. Reload the page in the web browser, then wait at least five seconds. Stop the Wireshark capture session. Set the Wireshark display filter to "tcp.port == 80" or even

tcp.port == 80 && ip.addr == 172.21.7.11

so that you only see packets that are part of a connection between your computer and port 80 on the math server. Find and describe the packets that are part of the three-way handshake that set up the connection, and examine the packets that are part of the handshake that closed the connection. Describe the packets. What flags are set in the packets? What, if anything, was set in the Options section of the SYN and SYNACK packets, and can you figure out what any of the Options mean? Which side closed the connection? Did the closing handshake follow the pattern shown in the book, which involved four packets (two FIN and two ACK packets)? And an old question related to HTTP: Why did I tell you to wait at least five seconds after loading the page before stoping the capture session? (Note: Wireshark shows time in seconds, in the first column in the packet list.)

Question 2: Continue the analysis of the same TCP connection. 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? How 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 3: After a TCP connection is closed, the side 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 that this state 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 information from the netstat -tnc command; if you don't already have that command running, do it now. Part of the output from netstat 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 that, use the command

telnet math.hws.edu 80

Then, instead of sending any command to the web server, 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 4: Keep netstat running while you do this question. Start up WireShark again, if it's not already running. Use "tcp.port == 23" as the display 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? Next, answer the same questions for a non-existent IP address on the HWS network. You can use "telnet 172.21.7.112." Speculate about the reason for the difference in the results for the two IP addresses.

Part 2: Analyzing File Uploads

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

For this part of the lab, you will use the files /classes/cs441/alice.txt, which is a 149KB copy of the book Alice in Wonderland, and bigpic.png, which is a 1.2MB image file. Actually, any files of similar sizes would work just as well.) You will be uploading these files to two web sites, one in Massachusetts provided by the textbook, and one on the department's web server. You will use Wireshark to look at the TCP connection for each of the four uploads. The two upload pages are at the following URL's (but don't upload any files until you have Wireshark ready):

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

            http://math.hws.edu/eck/cs441/upload.html

You might want to save the captured packets from each upload. When you save the captured packets in a file, you will be able to open that file later to continue analyzing the packets. The files will be listed in Wireshark's first window, and you just have to double-click a file name to reload the saved packets into Wireshark. (Later, if you want to get rid of the list of saved files, use "File" menu / "Open Recent" / "Clear Menu".)

You will do four uploads: two files to two servers. Start by going to the first upload page shown above. Start a WireShark capture session, and upload the file /classes/cs441/alice.txt. As soon as the file has been completely sent, you can stop the capture session. (It is better in this case not to wait the five extra seconds before stopping the capture session, because it is better to not include the handshake that closes the connection.)

You only want to look at TCP packets from the file upload, so you can use "tcp.port == 80" as the display filter. (If there are still packets in the list from other connections, you can add an "ip.addr" condition to the packet filter, as for Questions 1 above.)

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 the sequence number in a few more outgoing packets. How does the sequence number change from one packet to the next? Why? Now 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 (not the acknowledgement number) in each of these packets? Why?

---

For the remaining questions, you should base your answers on four file uploads, one from each of the two files to each of the two web sites. You do not necessarily have to answer the questions separately for each upload, but you should note any interesting variations and comparisons. You might want to repeat some of the uploads to get interesting results. You might want to print out some graphs and turn them in with your report. (use the "Save As" button in the bottom right corner of Wireshark's graph display window.)

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. When uploading a file, is there 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. Select any outgoing TCP packet, except for the initial SYN packet. (Make sure you have clicked on an outgoing packet!) Then select the "Round Trip Time Graph" command from the "TCP Stream Graph" sub-menu of the "Statistics" menu. Discuss how the RTTs change, if they do. (Note: I could only get Wireshark to display a non-empty "Round Trip Time Graph" by selecting a different graph from the list on the bottom left of the graph display window, then selecting "Round Trip Time Graph" again in the list.)

Question 7: Is a separate ACK received for each data packet? Can you find any duplicate ACKs or retransmitted packets or other interesting event? (Hint: there might be some dark black lines in the right margin of the packet list.)

Question 8: Now look at the "Time Sequence Graph (Stevens)" graph, which is another option in the list of graphs in the graph display window. 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? Can you interpret the pattern? 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? (The answer might be, "Not quite.")

Question 9: One might expect uploads to a remote site to have different characteristics from uploads to a server on the local network. Comment on any differences between this local uploads and the remote uploads. How do the RTTs compare? How do the total upload times compare? Any other interesting observations?