Lab Sheet

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.

Run NetXRay and create an Advanced filter that captures TCP/FTP packets. You need to use the "+" beside IP, the "+" beside TCP and then click in the "FTP" box. This is an important starting point in case there is traffic using other protocols on your network which is not of interest in this week's lab.

2. Start a capture.

3. From a DOS box use the FTP (File Transfer Protocol) program to start an FTP session with an FTP server.
- FTP
- Within the FTP window type "open (((FTPServer)))".
- If the server address has been given as a DNS name rather than a numeric IP address you will need to find out the IP address - use "ping -a <hostname>" and note down the IP address of the host. ("-a" forces ping to display this information)
- Connect using (((FTPCredentials)))

4. Once you have logged in, halt the capturing process and observe the packets held in the capture buffer. (You may close the FTP application, if you wish, by typing "bye").

5. Look first at the "Layer" column in the packet list. This tells you what the main purpose of each packet is - in earlier labs you might have seen "ARP" in this column. Today, if you have filtered correctly, you should see a mixture of "TCP" and "FTP".

6. Today we will be trying examine the "TCP" packets but to start off with select an "FTP" packet ( capture again if you do not have one )

Inspecting the IP header

Look at the summary of the headers in this packet that is displayed in the decode. Notice that, even though the packet has an FTP section in it, there is still a TCP and an IP header as well. The IP header was referred to in lectures as the "Datagram Header" and contains the overall "remote" addressing for the packet.

2. Expand the IP header ( click on the sign ) and inspect the IP addresses. Click on them and notice how they are highlit in the raw data of the packet. In the decode window they have been translated into decimal - for human consumption, whereas in the raw data window you see the actual 4 bytes - represented in hexadecimal. Try the translation yourself - use the Windows Calculator Start/Programs/Accessories/Calculator selecting View/Scientific to give "Mode" buttons for hexadecimal and decimal.

Inspecting the TCP header

Contract the IP header and then expand the TCP header. The TCP header is the section of the packet that manages reliability - this week's topic.

2. Expand the field within the TCP header named "Code"

3. How big ( how many bits ) is the Code field

4. To answer this you may like to look at the raw data and remember that every hexadecimal "digit" ( eg '1', 'A', '9' ) represents 4 bits.

5. Each bit has a special significance in terms of managing the connection between your PC and the host that you are connected to.
- PSH means that that there is some data in the packet. If you are looking at an "FTP" packet then PSH should be set because data is being transferred.
- ACK is an acknowledgment and is used throughout the conversation to acknowledge the previous packet. Often ACK and PSH will both be set meaning that we are sending some new data at the same time as sending an acknowledgment. Find a packet with ACK and PSH set ( recapture if necessary )
- SYN and FIN are to do with setting up and ending connections and this will be the main focus in the rest of the lab. Have you captured any packets with SYN set

6. Notice the two large number fields ( Sequence Number and Acknowledgment Number ). Click on either of these fields and note how many bytes are being used in the raw data section.

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.

The first of the three is a SYN ( synchronise sequence number ) packet. Find this packet and write down the sequence number that is being proposed at this stage. This is the number that your PC is intending to start counting from for this connection. Notice that there is no acknowledgment number yet.

The second packet is ACK, SYN ( acknowledging a synchronisation request ) In this packet the remote host is also proposing a sequence number. Write down the sequence number that the remote host is proposing:

and the acknowledgment number that was used in this packet noting that it is one greater than the SYN that your PC proposed:

The third packet is simply an ACK. Write down the acknowledgment number of this packet noting, in terms of numbers, what is being acknowledged:

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.

How many bytes were sent in packet 4 ( count them individually if you like but knowing that there are 16 bytes in each row of the data dispaly makes things quicker )

What was the sequence number of packet 4

What do you predict as the acknowledgment number in packet 5

What was it in fact

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.