BCIT COMP 7005 TCP and FTP Protocol Analysis Final Project by Wesley Kenzie, December 2010

8/8/2019 BCIT COMP 7005 TCP and FTP Protocol Analysis Final Project by Wesley Kenzie, December 2010

1/117

BCIT Computing and Information TechnologyCOMP 7005 Data Communication PrinciplesDue Date: December 7, 2010Author: Arthur (Wesley) Kenzie A00242330Final Project: TCP/IP and FTP Protocol Analysis (Final Version)______________________________________________________________________________

______________________________________________________________________________Copyright 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 1 of 117

This assignment undertakes an analysis of the TCP and FTP protocols, through a comparison ofpackets captured by Wireshark[8] and TShark[12] during 5 separate uploads of a 3.29 MB text fileusing unsecured, standard FTP to a remote server. FTP was chosen in order to easily observe thecontents of the TCP packet payloads, and easily compare these payloads to the text file contents.A detailed analysis of the FTP protocol is included only for the first upload.

The remote dedicated server was physically located in Luxembourg, on the European continent, atIP address 212.117.175.194, and running Ubuntu[9] 10.04.1 Server. It was running the Pure-FTPd[13] FTP server on port 20 and 21 for the purposes of this project. The remote server was notbusy, running almost no other processes at the time of each upload.

The text file uploaded in each case was the Wordlist.txt file, containing a list of over 306,000words and letter combinations. A copy of this file is included on the accompanying DVD.

(1) Upload from XubuntuDesktop client ......................................................... page 2

(2) Upload through the Tornetwork, from Ubuntu Desktop client, running in a VM, on a MicrosoftWindow 7 desktop ........................................................................................ page 83

(3) Upload from same Ubuntu Desktop VM client, not through Tornetwork ......... page 89

(4) Upload from Windows 7 Ultimate desktop .................................................. page 95

(5) Upload from dedicated Internet server running Ubuntu Server ..................... page 102

Summaries and Conclusions ...................................................................... page 107

Bibliography .............................................................................................. page 116

Credits ....................................................................................................... page 117


2/117



(1) Upload from Xubuntu Desktop client

This file upload was done from an Xubuntu[7] 10.04.1 Desktop client console using command-lineftp.

The accompanying fp1_filtered.pcap file, captured on the client, shows the initial SYN packet no.74 at time 2010-11-21 21:19:46.373183 (packet 18060 in the fp1_original.pcap file) sent fromthe client at 192.168.0.196 to the server at 212.117.175.194 attempting to establish a TCPconnection to port 21 on the server, which is the standard FTP control port. All previous packets inthe .pcap file before no. 74 can be ignored for the purposes of this project.

Packet 75 in the above snapshot shows the SYN-ACK response from the server to the client, andpacket 76 shows the ACK from the client to the server, completing the 3-way handshake. Afterpacket 76 there is an established TCP connection between port 46485 on the client and port 21 onthe server.


3/117



Note the 6-byte source MAC address 00:21:70:5e:fc:14 shown highlighted below in blue, which ispart of the 14-byte link-layer Ethernet II[2] protocol in the number 74 SYN packet. This MACaddress is the hardware address of the Dell Ethernet network interface card in this machine. The2-byte Type field 0x0800 indicates this packet is encapsulating an IP (IPv4) frame.


4/117



The 6-byte destination MAC address 00:18:E7:E1:B5:0A shown above in the link-layer is that ofthe D-Link router used by this computer, as shown below in the LAN section of the routers webmanagement interface, along with the gateway IP address 192.168.0.1 of the private subnet thecomputer is part of. The MAC address of the destination IP address 212.117.175.194 is notknown, of course, because it is not part of the private subnet to which the 192.168.0.196 client isconnected to.


5/117



Note the 20-byte IP header in the initial packet no. 74 SYN, which is highlighted below in blue. Itshows that IP version 4 is being used, the do not fragment flag is set, the source IP address is192.168.0.196, and the destination IP address is 212.117.175.194.


6/117



Note the 40-byte TCP header in packet 74, highlighted below in blue, showing the source anddestination ports, the SYN flag, and the advertised (client-side) window size of 5840 bytes:


7/117



A portion of the TCP SYN-ACK packet 75 is shown below. Note the Destination (highlighted inblue) and Source MAC addresses are reversed in the link-layer frame of this packet reversedfrom the previous SYN packet 74. The Dell computer (client) is receiving the packet from therouter/gateway here.


8/117



The 20-byte IP header for packet 75 coming from the remote server to the client is shownhighlighted below:


9/117



The 40-byte TCP header for packet 75 is shown highlighted below, with source port, destinationport, (relative) sequence number, (relative) acknowledgement number, SYN and ACK flags,server-side window size, and checksum:


10/117



The link-layer for ACK packet 76 is shown highlighted below:


11/117



The 20-byte IP header for packet 76 is shown highlighted below:


12/117



The 32-byte TCP header for packet 76 is shown highlighted below:

At the completion of packet 76 the TCP connection has been established between port 46485 onthe client and port 21 on the remote server.


13/117



Starting with packet 77 the FTP protocol negotiation begins, from the remote server to the client,over the TCP connection which has just been established. This packet 77 encapsulates the IP, TCPand FTP protocols as shown below. The total 386 bytes in this packet is composed of the 14-bytelink-layer, 20-byte IP header, 32-byte TCP header, and a 320-byte FTP payload.


14/117


15/117



The packet 77 FTP frame (TCP payload) is shown highlighted below. The FTP status 220 messagesindicate the FTP server is ready for a new user to negotiation a connection with it[3].


16/117



Packet 78 is shown below. This is simply a TCP ACK from the client to the server indicating thatthe packet 77 FTP status 220 message was received. Note that the (Relative) AcknowledgementNumber is 321.


17/117



Packet 79 is shown below. Note that it is sent from the client to the remote server nearly 18seconds after packet 78. This delay is primarily the result of the client ftp program waiting for theuser to enter a login (USER) name in this case the login name is wkenzie as shown below inthe FTP frame. This packet 79 is made up of the 14-byte FTP frame, the 32-byte TCP header, the20-byte IP header, and the 14-byte link-layer, for a total of 80 bytes in the packet.


18/117



The TCP header for packet 79 is shown below. Note that the PSH-ACK flags are set, indicating thatit is also sending acknowledgement number 321 (as was packet 78), and that it includes a datapayload the FTP frame.


19/117



Packets 80 and 81 are the servers responses to the clients FTP USER record sent in packet 79.Packet 80 is simply a TCP ACK, and packet 81 is a TCP PSH-ACK with the data payload being anFTP status 331 record.


20/117



The packet 80 TCP header is highlighted below in blue. Note the (relative) TCP sequence number(coming from the server) is now 321, after sending 320 bytes in packet 77 to the client. Note alsothe acknowledgement number 15, after receiving 14 bytes from the client in packet 79.


21/117



On overview of the encapsulated protocols in packet 81 is shown below: IP, TCP and FTP.


22/117



The packet 81 TCP header is highlighted below. Note the acknowledgement number is the sameas in packet 80, and flags are set for both PSH and ACK.


23/117



The packet 81 FTP frame is shown below. It consists of an FTP status 331 record, indicating to theftp client that the user/login wkenzie was accepted, and now a password is needed.


24/117



Packets 82 and 83 show the clients responses to the servers packet 81. Packet 82 is a TCP ACKwith acknowledgement number 361, representing the 40 bytes sent in the FTP portion of packet81 from the server added to the most recent acknowledgement number 321 sent from the clientin both packets 78 and 79.


25/117



Packet 83 shown below shows the next FTP PASS record as part of the FTP protocol beingnegotiated. The password being sent to the server (in the clear, as specified by the FTP protocol)is shown as m0narch550. The 83 bytes in packet 83 are made up of the 17 byte FTP datapayload, 32-byte TCP header, 20-byte IP header, and 14-byte link-layer.


26/117



Packets 84 and 85 are the servers responses to the clients FTP PASS record sent in packet 83.Packet 84 is simply a TCP ACK, and packet 85 is a TCP PSH-ACK with the data payload being anFTP status 230 record. Note acknowledgement number is now 32, which represents the 17 byteFTP data payload received in packet 83, added to the most recent acknowledgement number 15sent from the server in both packets 80 and 81. The sequence number 361 matches the mostrecent acknowledgement number 361 received from the client in both packets 82 and 83.


27/117



The packet 85 FTP data payload sent from the server to the client is shown below. It is an FTPstatus 230 record, indicating the PASS password has been accepted, the USER at the client sidecan now begin sending FTP commands to the server, the USER wkenzie belongs to the groupwkenzie on the server, and the current directory on the server is now /home/wkenzie.


28/117





29/117



The packet 87 TCP header shown below shows the TCP sequence number is now 32, whichrepresents the 17 bytes sent previously from the client in packet 83, added to the sequencenumber 15 in packet 83. Note the TCP flags are set for both PSH and ACK again, indicating thereis a data payload in this packet, in the form of an FTP frame.


30/117



The packet 87 FTP frame is shown below. It consists simply of an FTP SYST [3][14] command,which is a request from the client for the server to identify its operating system.


31/117



Packets 88 and 89 are the servers responses to the clients FTP SYST record sent in packet 87.Packet 88 is simply a TCP ACK, and packet 89 is a TCP PSH-ACK with the data payload being anFTP status 215 record. Note acknowledgement number is now 38, which represents the 6-byteFTP data payload received in packet 87, added to the most recent acknowledgement number 32sent from the server in both packets 84 and 85. The sequence number 456 matches the mostrecent acknowledgement number 456 received from the client in both packets 86 and 87.


32/117



The packet 89 FTP data payload sent from the server to the client is shown below. It is an FTPstatus 215 record, indicating the operating system on the server is running UNIX, type L8.


33/117





34/117



The packet 91 TCP header shown below shows the TCP sequence number is now 38, whichrepresents the 6 bytes sent previously from the client in packet 87, added to the sequencenumber 32 in packet 87. Note the TCP flags are set for both PSH and ACK again, indicating thereis a data payload in this packet, in the form of an FTP frame.


35/117



The packet 91 FTP frame is shown below. It consists of an FTP PORT [3][14] command, which is arequest from the client for the server to use port 43769 as the client-side port for subsequent filetransfers. This port 43769 is calculated as (170 * 256) + 249, where 170 and 249 are the 5th and6th parameters passed in the PORT command. The first 4 parameters 192, 168, 0, and 196 makeup the client IP address 192.168.0.196. It is expected that the server will attempt to establish aTCP connection from the servers FTP data port (20 is the default) to the clients port 43769 insubsequent packets. Note that packet 91 was sent about 10.5 seconds after packet 90, which is afairly significant delay. It is postulated that during this time the client machine was probing itsown port numbers to determine which port it could tell the server to use.


36/117



Packet 92 breaks the pattern thus far whereby the server responds to the client with both an ACKand a PSH-ACK packet. There is no separate ACK packet here, and packet 92 is a PSH-ACKresponse to the client PORT record sent in packet 91. This response appears below as an FTPstatus 200 record as the TCP data payload. Note acknowledgement number is now 66, whichrepresents the 28-byte FTP data payload received in packet 91, added to the most recentacknowledgement number 38 sent from the server in both packets 90 and 91. The sequencenumber 475 matches the most recent acknowledgement number 475 received from the client inboth packets 90 and 91.


37/117



The packet 92 FTP data payload sent from the server to the client is shown below. It is an FTPstatus 200 record, indicating the PORT command received in packet 91 is okay/valid and has beenaccepted.


38/117





39/117



The packet 94 TCP header shown below shows the TCP sequence number is now 66, whichrepresents the 28 bytes sent previously from the client in the FTP portion of packet 91, added tothe most recent sequence number 38 sent from the client in both packets 90 and 91. Note theTCP flags are set for both PSH and ACK again, indicating there is a data payload in this packet, inthe form of an FTP frame.


40/117



The packet 94 FTP frame is shown below. It consists of an FTP LIST [3][14] command, with noparameters, which is a request from the client for the server to send a list of files in the defaultdirectory, which in this case is known to be /home/wkenzie as indicated in the previous serverresponse to the client successfully logging in to the ftp server.


41/117



Packet 95 begins a new phase of the FTP negotiation, as shown below. It is a TCP SYN packet,sent from the server port 20 (standard FTP data port) to the client port 43769 (as previouslyspecified by the client in the packet 91 PORT command sent to the server). The TCP (relative)sequence number has been reset to 0.


42/117



Packet 96 sends a TCP SYN-ACK response back to the server.


43/117



Packet 98 completes the TCP 3-way handshake, with a TCP ACK packet being sent from the serverto the client to establish a TCP connection from server port 20 to client port 43769. Note thatpacket 97 appears somewhat out of sequence here, since it is a TCP ACK to the packet 94 FTPLIST command. Packet 97, along with packet 100, will be discussed later.


44/117



Packet 99 is a rather surprising TCP FIN-ACK packet, sent from the server to the client, indicatingthat the previous TCP connection which was only established in packet 98 - should now beclosed. It is speculated that this sequence of packets 95, 96, and 98 to establish a connection,followed by packets 99 (server FIN-ACK), 101 (client FIN-ACK), and 104 (server ACK) to close it,is done merely as a means to verify that a connection can be made between the server port 20and client port 43769.


45/117



Going back to packet 97, it is a TCP ACK packet, from the server to the client, in response to thepacket 94 FTP LIST command sent from the client. Packet 97 goes along with packet 100, which isshown on the next page.


46/117



Packet 100 is the servers response to the packet 94 FTP LIST command sent from the client. It isa TCP PSH-ACK packet, indicating there is an FTP data payload frame encapsulated in it. The TCPacknowledgement number 72 represents the 6-byte FTP data payload received in packet 94,added to the most recent acknowledgement number 66 sent from the client in both packets 93and 94. The sequence number 504 matches the most recent acknowledgement number 504received from the client in both packets 93 and 94.


47/117



The packet 100 FTP payload is a status 150 record. It appears to have arrived out of sequence,since it is signalling to the client that the server will open a data connection to client port 43769,but that work was already started in packet 95, with the TCP SYN packet sent from the server tothe client. In fact, packet 98 completed that connection opening.


48/117



Packet 102 likewise appears to have arrived out of sequence. It is an FTP status 226 record, fromthe server to the client, indicating that the data connection is going to be closed. However, theclosing of that connection was already started with packet 99, and continued with packets 101and 104.


49/117



Packet 103, from the client to the server, is simply a TCP ACK packet, in response to the previouspacket 102.


50/117



Packet 105 continues with the FTP protocol negotiation between the client and the server, asshown below. It shows the sending of the FTP TYPE[3][14] command to the server, indicating thatthe default file type should be I, meaning image. It is presumed that image file typeindicates that files are to be transferred as binary types, rather than text types.


51/117



Packets 106 and 107 are sent from the server in response to packet 105. Packet 106 is simply theTCP ACK packet, and packet 107 is shown below as the FTP status 200 record, confirming receiptof the packet 105 TYPE I command.


52/117



Packet 108 is another FTP PORT command sent from the client to the server. The previous PORTcommand in packet 91 appears to have been forgotten for some reason. In this case, the client istelling the server to use port 33823 on the client for subsequent FTP data connections (calculatedas (132*256) + 31 = 33823. The TCP header in this packet is a PSH-ACK packet.


53/117



Packet 109 is also a TCP PSH-ACK packet, with the FTP status 200 record sent from the server tothe client, indicating that the PORT command sent in packet 108 is considered valid.


54/117



Packet 110 is the next step in the FTP protocol negotiation, with the client sending an FTPSTOR[3][14] command to the server, along with the name of the file on the client side to beuploaded to the server. Note that this packets timestamp, at 21:21:06, is very close in time to allpackets starting with packet 105, and ending with packet 112. It is presumed that betweenpackets 104 and 105 the end-user on the client side was entering the command to PUT the/media/KINGSTON/FinalProject/Wordlist.txt file onto the server, and the TYPE, STOR and PORTcommands in packets 105, 110, and 113 were generated by the client-side FTP softwaresubsequent to this.


55/117



Packet 111 is the servers (very quick) reply to the client STOR command sent in packet 110. It isnot immediately clear why the file specified in the STOR command cannot be opened, but it isclear that the STOR command cannot be processed. The server is responding with an FTP status553 record here.


56/117



Packets 112 and 113 represent another FTP PORT command sent from the client to the server.Packet 114 is the servers response, advising the client that the new client port number is valid. Itis presumed that none of these packets are actually useful, however, given that packet 111indicated that the file specified (in the STOR command) cannot be uploaded.


57/117



Packets 115 and 116 represent another attempt by the client to specify a file to be uploaded, inthis case identifying the file as /home/wkenzie. Of course, this is not correct, since this is adirectory on the server, not a file on the client to be uploaded, and packet 117 (like packet 111)sends an FTP status 553 record in response, indicating the STOR command is again invalid.


58/117



Packet 119 is yet another FTP PORT command sent from the client to the server, specifying yetanother client port to use for the file transfer. Packet 120 responds from the server with an FTPstatus 200 reply, again indicating this port is valid.


59/117



Packets 121 and 122 is shown to be the 3rd attempt by the client at getting the STOR commandright.


60/117



Packets 123, 124 and 126 show another 3-way TCP connection established between the serverFTP data port 20 and client port 46292, as specified in the clients last PORT packet sent in packet119. The TCP (relative) sequence number in packet shown below is again 0, indicating, along withthe SYN flag, that this is to be a new connection. Packet 124 is the TCP SYN-ACK reply from theclient, and packet 126 is the servers TCP ACK completing the 3-way handshake.


61/117



Packets 125 and 127 show the servers response to the clients FTP STOR command sent in packet122: first a TCP ACK packet, and then a TCP PSH-ACK packet with encapsulated FTP status 150record advising the client that the STOR command was valid, and a connection to client port46292 (as specified by the client in packet 119) will now be attempted. Packet 127 is anotherpacket received out of sequence, because the connection it is referring to has already been madeby packet 126.


62/117



Packet 128 is a relative milestone in the FTP protocol being negotiated here, as it represents thefirst packet that actually sends data from the client to the server. It has a (relative) sequencenumber of 1, as shown below. It is being sent (uploaded) from client port 46292 to server port20, in 1448 byte chunks. This quantity 1448 is set by the limit of 1500-byte packets (which is1514 with the link-layer header included), minus the 20-byte IP header, minus the 32-byte TCPheader, which is 1500 minus 52 bytes of header data.


63/117



Packet 128 has the FTP data encapsulated as a TCP payload as shown below. Note that the firstfew characters of the data are !@#$%\r\n which represents the first record in the Wordlist.txt fileas shown in the image below the packet capture data, with the \r\n being new line and carriagereturn characters to mark the end of a record/line.


64/117



Packets 128, 129, and 130 are all sent by the client one after another, without pause for an ACKfrom the server. Packet 130 is shown below, with a (relative) sequence number of 2897,representing the starting sequence in packet 128 of 1, plus 1448 bytes sent in packet 128, plusanother 1448 bytes sent in packet 129. (1448 + 1448 = 2896)

The TCP window size specified by the server in packet 126 was 5888. By sending 3 packets of1500 bytes each, the client is effectively sending 4500 bytes of the 5888 advertised window buffersize on the server. One more packet of 1500 bytes would put it at 6000 - over this window size.Therefore it is presumed that TCP congestion control is at work here, with the servers initialadvertised window size limiting the client to sending 3 packets at a time.


65/117



Packet 131 is a TCP ACK packet sent from the client in response to the servers packet 127 FTPstatus 150 response. The TCP (relative) sequence number here is 264, which represents the 33bytes sent in the most recently sent on this connection packet 122, plus the sequence number ofthat packet, 231. The acknowledgement number here is 815, which represents the 30 bytesreceived in the most recently received on this connection packet 127, plus the sequence numberof that packet, 785.


66/117



Packet 132 (shown below at 21:21:33.585024) begins a series of similar packets, with a TCP ACKfrom the server, followed by 2 or 3 or 4 FTP-DATA packets from the client to the server. Thispattern of packets continues for about 33 seconds, until the last 100 bytes of the file are uploadedfrom the client to the server in packet 3992 at 21:22:06.605603 (shown on the next page).


67/117



Packet 3992 is the last packet sending data from the client to the server. It is the first, and only,packet that sets the TCP flags FIN, PSH, and ACK, indicating the upload of the file is now completeas far as the client is concerned. Packet 4032 (shown on the next page) is a TCP ACK from theserver to packet 3992.


68/117



Packet 4032 shown below is the servers TCP ACK to packet 3992 from the client. Note that it isstill showing as (relative) sequence number 1. Note also that the (server-side) TCP window sizehas increased to 206,848 by this point.


69/117



Packet 4033 from the server is now advising the client it is closing its side of the TCP connection,with its FIN and ACK flags set. The client had previously sent a FIN-ACK in packet 3992 advisingthe server it was closing its side of the TCP connection. Packet 4034 finishes the TCP connectionshutdown with an ACK packet sent to the server, and the client port 46292 to server port 20connection is not seen in any further packets after this.


70/117



Further to the FTP protocol disconnection protocol, packet 4035 from the servers control port 21is seen below advising the client in an FTP status 226 record that the file upload has beencompleted successfully, and the data port connection is being closed. This packet 4035 appears tobe out of sequence, since the data port connection has already been closed at this point. Note theFTP status 226 record also gives the file transfer time measured as 33.766 seconds, and theaverage transfer rate as 99.96 Kbytes/s.


71/117



Packet 4036 sends a TCP ACK to the servers packet 4035, and then packet 4037 shown below isseen to send an FTP QUIT[3][14] command to the server, to begin shutdown of its FTP session.This is followed by a TCP ACK from the server in packet 4038, an FTP status 221 record from theserver in packet 4039, a TCP FIN-ACK from the server in packet 4040 to indicate shutdown of itsside of the server port 21 to client port 46485 connection, a TCP ACK from the client in packet4041 to the servers packet 4039 FTP status 221, a TCP FIN-ACK from the client in packet 4042 toadvise the server its side of the TCP connection is closed, and lastly in packet 4043 the serversends a TCP ACK to the client in response to packet 4042.


72/117



Looking at the Time/Sequence Graph generated by Wireshark[8] for this file upload, as shownbelow, it appears that there was a very steady transfer of file packets from the client to theserver.


73/117



As a counter-point to the apparently-steady Time/Sequence graph however, the equivalentThroughput Graph shows there were significant variations in the amount of data being uploadedat any given time. Specifically there were 6 steep declines in throughput, demonstrating thedynamic nature of TCP communication as it self-adjusts to various conditions affectingthroughput, based on its flow control and congestion control algorithms.


74/117



The RTT graph for this TCP transmission also clearly shows this dynamic nature of TCPcommunication. As the round-trip times increase to about the 1.3 second mark, TCPs congestionavoidance mechanisms kick in to limit the amount of slowdown in packet transmissions, and tokeep the packets flowing, as clearly demonstrated in the Time/Sequence graph above.


75/117



In looking for specific evidence of these dynamic changes, a number of TCP Window Update,TCP Retransmission, TCP Fast Retransmission, and TCP Duplicate ACK conditions (packets)were observed during the 33-34 second file transfer to the server, as follows:

45 duplicate ACKs of packet 753;Packet 757 TCP Retransmission;Packet 759 TCP Retransmission;Packet 766 TCP Retransmission;Packet 776 TCP Retransmission;Packet 786 TCP Retransmission;Packet 793 TCP Retransmission;Packet 800 TCP Retransmission;

Packet 807 TCP Retransmission;Packet 814 TCP Retransmission;Packet 818 TCP Retransmission;Packet 823 TCP Retransmission;Packet 828 TCP Retransmission;2 duplicate ACKs of packet 831;2 duplicate ACKs of packet 835;Packet 835 TCP Window update.2 duplicate ACKs of packet 842;Packet 842 TCP Window update.1 duplicate ACK of packet 850;Packet 850 TCP Window update.1 duplicate ACK of packet 856;

Packet 856 TCP Window update.1 duplicate ACK of packet 862;Packet 862 TCP Window update.1 duplicate ACK of packet 868;Packet 868 TCP Window update.Packet 874 TCP Window update.47 duplicate ACKs of packet 1087;Packet 1096 TCP Fast Retransmission;Packet 1126 TCP Retransmission;Packet 1151 TCP Retransmission;8 duplicate ACKs of packet 1174;Packet 1174 TCP Window update.Packet 1175 TCP Retransmission;Packet 1177 TCP Retransmission;9 duplicate ACKs of packet 1194;Packet 1194 TCP Window update.10 duplicate ACKs of packet 1216;Packet 1216 TCP Window update.42 duplicate ACKs of packet 1730;Packet 1734 TCP Retransmission;


76/117



Packet 1736 TCP Retransmission;

44 duplicate ACKs of packet 2274;Packet 2280 TCP Fast Retransmission;47 duplicate ACKs of packet 3022;

Packet 3030 TCP Fast Retransmission;Packet 3054 TCP Retransmission;Packet 3077 TCP Retransmission;Packet 3095 TCP Retransmission;Packet 3098 TCP Retransmission;7 duplicate ACKs of packet 3099;7 duplicate ACKs of packet 3117;Packet 3117 TCP Window update.4 duplicate ACKs of packet 3135;

Packet 3135 TCP Window update.46 duplicate ACKs of packet 3417;Packet 3423 TCP Fast Retransmission;Packet 3447 TCP Retransmission;Packet 3474 TCP Retransmission;7 duplicate ACKs of packet 3499;9 duplicate ACKs of packet 3517;Packet 3517 TCP Window update.36 duplicate ACKs of packet 3994;Packet 3997 TCP Fast Retransmission;

In reviewing the variety of server-side TCP window sizes, a spreadsheet was created showing thewindow size indicated on each packet sent from the server to the client. This spreadsheet is

included as a 31-page fp1_filtered_server_window_sizes.pdffile on the accompanying DVD, aswell as the fp1_filtered_server_window_sizes.xlsx spreadsheet itself. It shows the window sizestarting at 5840 bytes, climbing relatively quickly during the quick start phase to 64,128 bytes,then climbing more slowly to 109,696 bytes, before encountering the first errors beginning atpacket 756. The first reductions in window size start appearing at packet 830. The right-sideIncrease column tracks the changes in server-side windows size from packet to packet.


77/117



Packet 753 at the 5.729 second mark (shown below) is where the first instance of packettransmissions problems shows up. Actually, packet 753 had no problems, and was simply a TCPACK sent from the server to the client. However, packet 756 is a Duplicate ACK, sent just 0.013seconds after packet 753, and then repeated/duplicated again 44 more times, over the next 0.613seconds up to and including packet 829. Why the duplicate ACKs? Most likely because the serverhas encountered an out-of-order packet, and must therefore tell the client immediately, becauseTCP cannot determine if this out-of-order condition is perhaps caused by a lost packet that mustbe re-sent.

The TCP retransmissions starting at packet 757 and ending with packet 828 confirm that this islikely what is occurring here.


78/117



Packet 757 shown below is the first TCP retransmission packet. Note that it shows a (relative)sequence number 531,233 which is the same as the (relative) acknowledgement number specifiedin packet 756. So the TCP duplicate ACK in packet 756 is telling the client to go back and resendpacket 674, which the client immediately does in packet 757. Packet 674 is shown on the nextpage, and is identified by the (relative) sequence number 531,233 that it used.


79/117



Packet 674 is shown below, which is the first packet retransmitted (in packet 757). If we hadcaptured the TCP packets for this transmission on the server as well as on the client, we wouldlikely have been able to know whether packet 674 had been lost, or merely received out-of-order.


80/117



This duplicate ACK and subsequent retransmission condition appears a number of times during thelife of this file upload.

In the case of there being at least 36 duplicate ACKs sent from the server (the major duplicateACK condition), there is the condition encountered at packet 753, and then again at packets 1087,1730, 2274, 3022, 3417, and 3994.

The packet 1087 condition differed in that it resulted in the first Fast Retransmission packet ofthe file upload, as shown below. The client waited in this case for 3 duplicate ACKs, beforeinitiating a Fast Retransmit, whereas at packet 753 it did not. Fast Retransmission was the clientsresponse in 5 of the 7 major duplicate ACK conditions, and it is thus believed that the client TCPstack does not always wait for 3 duplicate ACKs before initiating a fast retransmission.


81/117



The 7 major TCP duplicate ACK conditions are summarized below, with the Recovery Secondscolumn representing the amount of time elapsed between the first duplicate ACK packet sent bythe server, to the last duplicate ACK packet after which the out-of-order or lost packet conditionwas resolved.

Packet No. ACK No. of No. of Last RecoveryDuplicated Number Duplicate ACKs Retransmissions Packet Seconds753 531,233 45 12 829 0.6271087 786,081 47 3 1170 0.6511730 1359,489 42 2 1803 0.5862274 1854,705 44 1 2350 0.6153022 2542,505 47 4 3097 0.656

3417 2878,441 45 3 3497 0.6413994 3402,617 36 1 4031 0.491

There is a remarkable amount of consistency between each of these 7 instances, which leads oneto speculate that this condition was either not caused by a random lost packet, or that theefficiency of recovery by TCP from a lost packet or out-of-order packet is relatively constant andpredictable. The following Wireshark[8] graph is quite interesting in this regard.


82/117



The remaining minor TCP duplicate ACK conditions are summarized as follows:

Packet No. ACK No. of No. of Last RecoveryDuplicated Number Duplicate ACKs Retransmissions Packet Seconds831 539,921 2 0 833 0.028835 550,057 2 0 839 0.029842 560,193 2 0 846 0.028850 567,433 1 0 852 0.015856 574,673 1 0 858 0.013862 581,913 1 0 864 0.015868 589,153 1 0 870 0.0131174 816,489 8 2 1190 0.113

1194 838,209 9 0 1212 0.1251216 857,033 10 0 1236 0.1413099 2567,121 7 0 3111 0.0853117 2588,841 7 0 3131 0.0963135 2610,561 4 0 3143 0.0683499 2903,057 7 0 3513 0.1083517 2927,673 9 0 3533 0.108

There is likely a significant difference in whatever condition caused these minor duplicate ACKscompared to the previous major condition. Further research using both client and server packetcapture should provide more information to help identify what this difference might be.


83/117



(2) Upload from Ubuntu Desktop VM client through Tor

This file upload was done through the Tor[5] network, from an Ubuntu[9] 10.04.1 Desktop clientconsole running in VMware[10] Workstation VM on Microsoft Windows[11] 7 Ultimate desktop, withcommand-line ftp wrapped inside usewithtor, as shown below.

The p argument starts ftp in passive mode, so that only 1 server port is used, rather than 1each for control and data communications. This was done to allow it to be used through the Tornetwork. The v argument passed to ftp enables verbose mode. sudo, of course, is the Ubuntusuper user do it command. usewithtor is a shell wrapper that forces ftp to use the locallyinstalled and running Tor instance on local port 9050.

The accompanying fp2_filtered.pcap and fp2_original.pcap files, which were captured on theclient, does not show any of the normal TCP or FTP protocol information because the Tor networkencrypts all of its packets.

Note that the above snapshot shows the file upload completed in 172.221 seconds, at 19.6Kbytes/s compared to the 33.766 seconds, at 99.96 Kbytes/s. This is a factor of 5.1 times slower,when done from a Windows-based Ubuntu VM session through Tor compared to a local Xubuntuinstance as in Upload 1.


84/117



The following screen shows the man page for the usewithtor program wrapper:


85/117



The following screen shows the Ubuntu configuration setting to force all locally transmittedpackets to enter the Tor network at local port 9050:


86/117



The Time/Sequence Graph generated by Wireshark[8] for Upload 2 is shown below. It appears thatthere was a clear TCP fast start phase, followed by a relatively steady transfer of file packetsfrom the client to the server. This is discussed further in the Summaries and Conclusions sectionof this assignment.


87/117



The Upload 2 Throughput Graph generated by Wireshark[8] is shown below, and discussed in theSummaries and Conclusions section of this assignment.


88/117



The corresponding RTT Graph for Upload 2 is shown below, and also discussed in the Summariesand Conclusions section of this assignment.


89/117



(3) Upload from same Ubuntu Desktop VM client, not through Tor

This file upload was done from the same (as Upload 2) Ubuntu[9] 10.04.1 Desktop client consolerunning in VMware[10] Workstation VM on Microsoft Windows[11] 7 Ultimate desktop, withcommand-line ftp, but not through the Tor[5] network. This is shown below.

Note the upload was done in 34.00 seconds, which was just slightly slower than Upload 1.

Wireshark[8] was running simultaneously on the same client machine as the VM, and the resultantfp3_filtered.pcap and fp3_original.pcap files are included on the accompanying DVD.


90/117



The following screen shows the Ubuntu configuration setting to make a direct connection to theInternet, rather than using a locally running proxy:


91/117



The Time/Sequence Graph generated by Wireshark[8] for Upload 3 is shown below. Similar toUpload 2, there appears to be a clear TCP fast start phase, followed by a relatively steadytransfer of file packets from the client to the server. This is discussed further in

BCIT COMP 7005 TCP and FTP Protocol Analysis Final Project by Wesley Kenzie, December 2010

Documents

Transcript of BCIT COMP 7005 TCP and FTP Protocol Analysis Final Project by Wesley Kenzie, December 2010