This is an old version of this course, from Fall 2016. A newer version is available here.
Resources
The prelab and lab packet for this lab are individual. You will work in teams of two during lab, but write your own packet.
- Lab Checklist — I will provide a paper copy of this.
- Prelab — I will provide a paper copy of this.
Please wait until you come to lab to do the Wireshark captures. You should do the entire prelab individually before lab (excepting the writing of the modified code, which just one team-member can do). Please work in teams of two unless approved by the instructor. Please submit one lab packet per team member.
Prelab
Complete the prelab packet, handed out during the Week 7 Lab period.
Write the modified version of tcp_send in the Lab 4 code. (Since this is not turned in, it's OK if only one member of the in-lab team writes it. But I recommend checking with your lab partner to make sure you agree about who will do this!)
In-lab
Write your lab partner's name in the extra blank on your lab checklist.
- Working in teams of two, you will be running and modifying your TCP client and server code from Lab 4, and they must be run on separate machines. You will need to locate the IP addresses of your machines for the TCP code as well as to add a filter to Wireshark. If your Lab 4 is not correctly closing the connection, simplify the protocol that both the sender and receiver use to send data. For example, the sender could only send "X's" until the end, when it sends a 'Q'. The receiver could continually receive only one byte until it receives the 'Q', and then exit.
- Fire up Wireshark on both machines. Since you may have quite a bit of network traffic that we are not interested in, create a capture filter for your partner's machine. I recommend something along the lines of
ip.host == "155.192.xxx.yyy"
- With the capture running on both machines, invoke the server (tcp_receive) and client (tcp_send). Both machines should capture the same conversation. Locate the SYN, SYN/ACK, ACK three-way handshake, and the pair of FIN, ACKs at the end of the conversation. Also note the Data portion of the TCP packets and locate the actual messages exchanged. Note any discrepancies between the captures on the two machines.
- In the segments containing data, note the win=XXXXX. This is the window advertisement and hence the amount of data the sender of that packet is able to receive.
- Now, modify tcp_send to load the receiver and network:
- tcp_send: Modify to send large amounts of data. For example, instead of accepting input from the user, send a line of text with 10000 characters and send it 10 times in a loop. The code message = 'X' * 10000 will result in a large string of Xs. If you use your correctly-working receiver from
Lab 6Lab 4, you will also need to throw in four binary bytes and an LF here and there. You are welcome, however, to modify both sender and receiver to use a simpler protocol to make it easier to close the connection cleanly. Keep sending more data until you start to see the network and/or receiver slow down. - As before, capture packets from this transaction. If you are not seeing any evidence of overwhelming the network or the receiver, add a sleep statement to the receiver, so that every time recv is called, it sleeps 100, 500, or 1000 ms. Run the capture and programs again. At this point you should see the window advertisement reach 0 and effectively halt transmission. Leave everything run for a few minute and observe the capture. You may need to exit with a Ctrl-C.
- Scroll through the capture and answer the questions in the handout.
- Pick out a packet that sent data. Write the sequence number as displayed in wireshark. Predict the sequence number for the next packet sent from the same source. Find the acknowledgement of this packet. What is its acknowledgement number?
- If you have time
- In your capture, try to locate any packets that were retransmitted. Try to characterize the cause of the retransmission (timeout, multiple ACKs) and describe below.
- Look at Wireshark's summary of the packet. From this alone, can you predict the byte-values for the source, destination, sequence, acknowledgement, and window fields of the packet? Can you predict the layout of the entire packet by putting in zeros for the fields you didn't predict so the byte alignment is correct?
(Acknowledgements: The original version of this lab written by Dr. Rothe.)