Lab 5: Reliability

Follow this lab sheet carefully, step by step, reading the explanations of what you are looking at.

This lab aims to provide reinforcement of the use of NetXRay. Remember that you will need to use it in next week's practical examination.

Task 1 - Observing TCP's 3-way handshake

In this exercise you will watch TCP setting up a connection, observing how it uses sequence numbers and three-way handshakes to achieve reliability. In order to create some TCP traffic, you will be using FTP, which uses TCP to deliver data.

Inspecting the IP header

Inspecting the TCP header
Inspecting the 3-way Handshake
The 3-way handshake is the sequence of packets that is used to set up a connection in the first place. In the lecture this was described as:
- A Requests a connection from B
- B acknowledges the request
- A confirms that that it's ready to go
A side effect of this "handshake" is that A and B have agreed on a sequence number starting point. You are now going to inspect this process in detail. To do this work you need a capture buffer that contains the three "TCP" packets that make up this handshake. If you capture during the sequence between ftp <host> and the ftp login prompt ( but do not log in ) then you should have the right packets.

It only remains to note that the Sequence Number in this packet has not been incremented. In the three way handshake the sequence numbers are only incremented on receipt of a SYN packet.

Task 2 - Finding a FIN

The last NetXRay task is to try and catch a packet with the FIN flag set ( end of connection ). To do this you will be creating the final type of NetXRay filter - a Data Pattern filter. This type of filter is one that you will be needing a lot in later labs so pay careful attention to what is going on here.

A Data Pattern filter can accept ( or reject ) packets that have a certain piece of data at a certain position in the packet. The assumption is that you have some idea of what it is that you want to accept or reject. Take the following steps:

1. Make sure that you still have a buffer with some of the packets from the earlier exercises and that the window is displayed. If not re-capture.

2. From the Filter Settings windows select the Data Pattern tab

3. Click on the Add Pattern button. If you have the data available ( first step above ) you should see a new decode window open up within the Edit Pattern screen. If this is not the case go back to step 1. You can move back and forth between your packets using the Next and Previous buttons.

4. Find a packet that has a TCP header ( shrink the other headers ) and locate the Code section of the TCP header ( it is displayed already expanded - RES, URG, ACK etc )

5. Click on one of these lines and then on the Set Data button. Notice what happens in the top of the screen. The precise position of the Code byte has been calculated ( Offset = 47 ), the length ( Len = 1 byte ) and the value inserted into the mini-spreadsheet. What value do you see

The value you see will be the value of the Code byte in the packet you are currently viewing so it is not yet the value that you want to go looking for.

6. The packets that we want to grab are ACK, FIN packets ( ie they have those two bits set ) Looking at the packet decode you should be able to see that this would be 00010001 in binary. What would that be in hex

7. Enter this hexadecimal value in the first cell of the mini-spreadsheet ( instead of the value that is there). Packets with this value, at that position, are the ones you want to capture!

8. Say "OK" to Edit Pattern and before leaving the Filter Setting window check that you still have the Advance Filter set for FTP ( there may be some non-TCP packets out there that have the same piece of data, in the same position, as the Data Pattern filter is looking in )

9. Start the capture.

10. Capture an FTP session - this time there should be no packets captured until you say "bye"

11. Inspect your packets - there should be two. The significance of ACK, FIN is that each end of the connection is winding up its sequence number series.

Task 3 - Sorting out sequence numbers

In this exercise you will examine the way that TCP calculates the acknowledgement number that it sends in response to a specific sequence number. The intention is that this acknowlegment number has the effect of confirming the reception of each byte that was sent. This is achieved by adding the number of bytes received to the sequence number in the packet and using that number as the acknowledgement number. The sender knew the sequence number and the number of bytes that was sent so this acknowldegment confirms that everything got there OK!

When you captured 5 packets at the beginning of an FTP session the first three were the 3-way handshake, as described, but the last two consisted of the server sending a login message which was acknowledged by your workstation. Confirm this by looking at the source and destination IP addresses for the last two packets and also at the TCP flags that were set in them.

If you do not have what seem like the right five packets repeat the capture as described above.

The only thing that can go wrong here is if there was ( unlikely ) an odd number of bytes sent. TCP will round the count upwards to next even number.