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

BCIT Computing and Information Technology
COMP 7005 Data Communication Principles

Due Date: December 7, 2010
Author: Arthur (Wesley) Kenzie A00242330
Final Project: TCP/IP and FTP Protocol Analysis (Final Version)
______________________________________________________________________________
This assignment undertakes an analysis of the TCP and FTP protocols, through a comparison of
packets captured by Wireshark[8] and TShark[12] during 5 separate uploads of a 3.29 MB text file
using unsecured, standard FTP to a remote server. FTP was chosen in order to easily observe the
contents 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, at
IP 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 not
busy, 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,000
words and letter combinations. A copy of this file is included on the accompanying DVD.
(1) Upload from Xubuntu Desktop client ......................................................... page 2
(2) Upload through the Tor network, from Ubuntu Desktop client, running in a VM, on a Microsoft
Window 7 desktop ........................................................................................ page 83
(3) Upload from same Ubuntu Desktop VM client, not through Tor network ......... 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
______________________________________________________________________________
Copyright © 2010. Arthur (Wesley) Kenzie. All Rights Reserved. Page 1 of 117
______________________________________________________________________________
(1) Upload from Xubuntu Desktop client
This file upload was done from an Xubuntu[7] 10.04.1 Desktop client console using command-line
ftp.
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 from
the client at 192.168.0.196 to the server at 212.117.175.194 attempting to establish a TCP
connection to port 21 on the server, which is the standard FTP control port. All previous packets in
the .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, and
packet 76 shows the ACK from the client to the server, completing the 3-way handshake. After
packet 76 there is an established TCP connection between port 46485 on the client and port 21 on
the server.
______________________________________________________________________________
______________________________________________________________________________
Note the 6-byte source MAC address 00:21:70:5e:fc:14 shown highlighted below in blue, which is
part of the 14-byte link-layer Ethernet II[2] protocol in the number 74 SYN packet. This MAC
address is the hardware address of the Dell Ethernet network interface card in this machine. The
2-byte Type field 0x0800 indicates this packet is encapsulating an “IP” (IPv4) frame.
______________________________________________________________________________
______________________________________________________________________________
The 6-byte destination MAC address 00:18:E7:E1:B5:0A shown above in the link-layer is that of
the D-Link router used by this computer, as shown below in the “LAN” section of the router’s web
management interface, along with the gateway IP address 192.168.0.1 of the private subnet the
computer is part of. The MAC address of the destination IP address 212.117.175.194 is not
known, of course, because it is not part of the private subnet to which the 192.168.0.196 client is
connected to.
______________________________________________________________________________
______________________________________________________________________________
Note the 20-byte IP header in the initial packet no. 74 SYN, which is highlighted below in blue. It
shows that IP version 4 is being used, the “do not fragment” flag is set, the source IP address is
192.168.0.196, and the destination IP address is 212.117.175.194.
______________________________________________________________________________
______________________________________________________________________________
Note the 40-byte TCP header in packet 74, highlighted below in blue, showing the source and
destination ports, the SYN flag, and the advertised (client-side) window size of 5840 bytes:
______________________________________________________________________________
______________________________________________________________________________
A portion of the TCP SYN-ACK packet 75 is shown below. Note the Destination (highlighted in
blue) and Source MAC addresses are reversed in the link-layer frame of this packet – reversed
from the previous SYN packet 74. The Dell computer (client) is receiving the packet from the
router/gateway here.
______________________________________________________________________________
______________________________________________________________________________
The 20-byte IP header for packet 75 coming from the remote server to the client is shown
highlighted below:
______________________________________________________________________________
______________________________________________________________________________
The 40-byte TCP header for packet 75 is shown highlighted below, with source port, destination
port, (relative) sequence number, (relative) acknowledgement number, SYN and ACK flags,
server-side window size, and checksum:
______________________________________________________________________________
______________________________________________________________________________
The link-layer for ACK packet 76 is shown highlighted below:
______________________________________________________________________________
______________________________________________________________________________
The 20-byte IP header for packet 76 is shown highlighted below:
______________________________________________________________________________
______________________________________________________________________________
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 on
the client and port 21 on the remote server.
______________________________________________________________________________
______________________________________________________________________________
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, TCP
and FTP protocols as shown below. The total 386 bytes in this packet is composed of the 14-byte
link-layer, 20-byte IP header, 32-byte TCP header, and a 320-byte FTP payload.
______________________________________________________________________________
______________________________________________________________________________
The 32-byte TCP header of packet 77 is shown highlighted below. Note that it is a PSH-ACK
packet, meaning that it includes a data payload – in this case the FTP frame. Note also the Next
(relative TCP) Sequence Number of 321, which is equal to the (Relative TCP) Sequence Number 1
plus the 320-byte size of the FTP frame.
______________________________________________________________________________
______________________________________________________________________________
The packet 77 FTP frame (TCP payload) is shown highlighted below. The FTP status 220 messages
indicate the FTP server is ready for a new user to negotiation a connection with it[3].
______________________________________________________________________________
______________________________________________________________________________
Packet 78 is shown below. This is simply a TCP ACK from the client to the server indicating that
the packet 77 FTP status 220 message was received. Note that the (Relative) Acknowledgement
Number is 321.
______________________________________________________________________________
______________________________________________________________________________
Packet 79 is shown below. Note that it is sent from the client to the remote server nearly 18
seconds after packet 78. This delay is primarily the result of the client ftp program waiting for the
user to enter a login (“USER”) name – in this case the login name is “wkenzie” as shown below in
the FTP frame. This packet 79 is made up of the 14-byte FTP frame, the 32-byte TCP header, the
20-byte IP header, and the 14-byte link-layer, for a total of 80 bytes in the packet.
______________________________________________________________________________
______________________________________________________________________________
The TCP header for packet 79 is shown below. Note that the PSH-ACK flags are set, indicating that
it is also sending acknowledgement number 321 (as was packet 78), and that it includes a data
payload – the FTP frame.
______________________________________________________________________________
______________________________________________________________________________
Packets 80 and 81 are the server’s responses to the client’s 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 an
FTP status 331 record.
______________________________________________________________________________
______________________________________________________________________________
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 also
the acknowledgement number 15, after receiving 14 bytes from the client in packet 79.
______________________________________________________________________________
______________________________________________________________________________
On overview of the encapsulated protocols in packet 81 is shown below: IP, TCP and FTP.
______________________________________________________________________________
______________________________________________________________________________
The packet 81 TCP header is highlighted below. Note the acknowledgement number is the same
as in packet 80, and flags are set for both PSH and ACK.
______________________________________________________________________________
______________________________________________________________________________
The packet 81 FTP frame is shown below. It consists of an FTP status 331 record, indicating to the
ftp client that the user/login “wkenzie” was accepted, and now a password is needed.
______________________________________________________________________________
______________________________________________________________________________
Packets 82 and 83 show the client’s responses to the server’s packet 81. Packet 82 is a TCP ACK
with acknowledgement number 361, representing the 40 bytes sent in the FTP portion of packet
81 from the server added to the most recent acknowledgement number 321 sent from the client
in both packets 78 and 79.
______________________________________________________________________________
______________________________________________________________________________
Packet 83 shown below shows the next FTP “PASS” record as part of the FTP protocol being
negotiated. 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 data
payload, 32-byte TCP header, 20-byte IP header, and 14-byte link-layer.
______________________________________________________________________________
______________________________________________________________________________
Packets 84 and 85 are the server’s responses to the client’s FTP “PASS” record sent in packet 83.
FTP status 230 record. Note acknowledgement number is now 32, which represents the 17 byte
FTP data payload received in packet 83, added to the most recent acknowledgement number 15
sent from the server in both packets 80 and 81. The sequence number 361 matches the most
recent acknowledgement number 361 received from the client in both packets 82 and 83.
______________________________________________________________________________
______________________________________________________________________________
The packet 85 FTP data payload sent from the server to the client is shown below. It is an FTP
status 230 record, indicating the PASS password has been accepted, the USER at the client side
can now begin sending FTP commands to the server, the USER “wkenzie” belongs to the group
“wkenzie” on the server, and the current directory on the server is now “/home/wkenzie”.
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
The packet 87 TCP header shown below shows the TCP sequence number is now 32, which
represents the 17 bytes sent previously from the client in packet 83, added to the sequence
number 15 in packet 83. Note the TCP flags are set for both PSH and ACK again, indicating there
is a data payload in this packet, in the form of an FTP frame.
______________________________________________________________________________
______________________________________________________________________________
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 it’s operating system.
______________________________________________________________________________
______________________________________________________________________________
Packets 88 and 89 are the server’s responses to the client’s FTP “SYST” record sent in packet 87.
FTP status 215 record. Note acknowledgement number is now 38, which represents the 6-byte
FTP data payload received in packet 87, added to the most recent acknowledgement number 32
sent from the server in both packets 84 and 85. The sequence number 456 matches the most
recent acknowledgement number 456 received from the client in both packets 86 and 87.
______________________________________________________________________________
______________________________________________________________________________
status 215 record, indicating the operating system on the server is running UNIX, type L8.
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
represents the 6 bytes sent previously from the client in packet 87, added to the sequence
number 32 in packet 87. Note the TCP flags are set for both PSH and ACK again, indicating there
is a data payload in this packet, in the form of an FTP frame.
______________________________________________________________________________
______________________________________________________________________________
The packet 91 FTP frame is shown below. It consists of an FTP “PORT” [3][14] command, which is a
request from the client for the server to use port 43769 as the client-side port for subsequent file
transfers. This port 43769 is calculated as (170 * 256) + 249, where 170 and 249 are the 5th and
6th parameters passed in the PORT command. The first 4 parameters 192, 168, 0, and 196 make
up the client IP address 192.168.0.196. It is expected that the server will attempt to establish a
TCP connection from the server’s FTP data port (20 is the default) to the client’s port 43769 in
subsequent packets. Note that packet 91 was sent about 10.5 seconds after packet 90, which is a
fairly significant delay. It is postulated that during this time the client machine was probing its
own port numbers to determine which port it could tell the server to use.
______________________________________________________________________________
______________________________________________________________________________
Packet 92 breaks the pattern thus far whereby the server responds to the client with both an ACK
and a PSH-ACK packet. There is no separate ACK packet here, and packet 92 is a PSH-ACK
response to the client “PORT” record sent in packet 91. This response appears below as an FTP
status 200 record as the TCP data payload. Note acknowledgement number is now 66, which
represents the 28-byte FTP data payload received in packet 91, added to the most recent
acknowledgement number 38 sent from the server in both packets 90 and 91. The sequence
number 475 matches the most recent acknowledgement number 475 received from the client in
both packets 90 and 91.
______________________________________________________________________________
______________________________________________________________________________
status 200 record, indicating the PORT command received in packet 91 is okay/valid and has been
accepted.
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
represents the 28 bytes sent previously from the client in the FTP portion of packet 91, added to
the most recent sequence number 38 sent from the client in both packets 90 and 91. Note the
TCP flags are set for both PSH and ACK again, indicating there is a data payload in this packet, in
the form of an FTP frame.
______________________________________________________________________________
______________________________________________________________________________
The packet 94 FTP frame is shown below. It consists of an FTP “LIST” [3][14] command, with no
parameters, which is a request from the client for the server to send a list of files in the default
directory, which in this case is known to be /home/wkenzie as indicated in the previous server
response to the client successfully logging in to the ftp server.
______________________________________________________________________________
______________________________________________________________________________
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 previously
specified by the client in the packet 91 PORT command sent to the server). The TCP (relative)
sequence number has been reset to 0.
______________________________________________________________________________
______________________________________________________________________________
Packet 96 sends a TCP SYN-ACK response back to the server.
______________________________________________________________________________
______________________________________________________________________________
Packet 98 completes the TCP 3-way handshake, with a TCP ACK packet being sent from the server
to the client to establish a TCP connection from server port 20 to client port 43769. Note that
packet 97 appears somewhat out of sequence here, since it is a TCP ACK to the packet 94 FTP
LIST command. Packet 97, along with packet 100, will be discussed later.
______________________________________________________________________________
______________________________________________________________________________
Packet 99 is a rather surprising TCP FIN-ACK packet, sent from the server to the client, indicating
that the previous TCP connection – which was only established in packet 98 - should now be
closed. 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 20
and client port 43769.
______________________________________________________________________________
______________________________________________________________________________
Going back to packet 97, it is a TCP ACK packet, from the server to the client, in response to the
packet 94 FTP LIST command sent from the client. Packet 97 goes along with packet 100, which is
shown on the next page.
______________________________________________________________________________
______________________________________________________________________________
Packet 100 is the server’s response to the packet 94 FTP LIST command sent from the client. It is
a TCP PSH-ACK packet, indicating there is an FTP data payload frame encapsulated in it. The TCP
acknowledgement 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 93
and 94. The sequence number 504 matches the most recent acknowledgement number 504
received from the client in both packets 93 and 94.
______________________________________________________________________________
______________________________________________________________________________
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 to
the client. In fact, packet 98 completed that connection opening.
______________________________________________________________________________
______________________________________________________________________________
Packet 102 likewise appears to have arrived out of sequence. It is an FTP status 226 record, from
the server to the client, indicating that the data connection is going to be closed. However, the
closing of that connection was already started with packet 99, and continued with packets 101
and 104.
______________________________________________________________________________
______________________________________________________________________________
Packet 103, from the client to the server, is simply a TCP ACK packet, in response to the previous
packet 102.
______________________________________________________________________________
______________________________________________________________________________
Packet 105 continues with the FTP protocol negotiation between the client and the server, as
shown below. It shows the sending of the FTP “TYPE”[3][14] command to the server, indicating that
the default file type should be “I”, meaning “image”. It is presumed that “image” file type
indicates that files are to be transferred as “binary” types, rather than “text” types.
______________________________________________________________________________
______________________________________________________________________________
Packets 106 and 107 are sent from the server in response to packet 105. Packet 106 is simply the
TCP ACK packet, and packet 107 is shown below as the FTP status 200 record, confirming receipt
of the packet 105 “TYPE I” command.
______________________________________________________________________________
______________________________________________________________________________
Packet 108 is another FTP “PORT” command sent from the client to the server. The previous PORT
command in packet 91 appears to have been forgotten for some reason. In this case, the client is
telling the server to use port 33823 on the client for subsequent FTP data connections (calculated
as (132*256) + 31 = 33823. The TCP header in this packet is a PSH-ACK packet.
______________________________________________________________________________
______________________________________________________________________________
Packet 109 is also a TCP PSH-ACK packet, with the FTP status 200 record sent from the server to
the client, indicating that the PORT command sent in packet 108 is considered valid.
______________________________________________________________________________
______________________________________________________________________________
Packet 110 is the next step in the FTP protocol negotiation, with the client sending an FTP
“STOR”[3][14] command to the server, along with the name of the file on the client side to be
uploaded to the server. Note that this packet’s timestamp, at 21:21:06, is very close in time to all
packets starting with packet 105, and ending with packet 112. It is presumed that between
packets 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 PORT
commands in packets 105, 110, and 113 were generated by the client-side FTP software
subsequent to this.
______________________________________________________________________________
______________________________________________________________________________
Packet 111 is the server’s (very quick) reply to the client STOR command sent in packet 110. It is
not immediately clear why the file specified in the STOR command cannot be opened, but it is
clear that the STOR command cannot be processed. The server is responding with an FTP status
553 record here.
______________________________________________________________________________
______________________________________________________________________________
Packets 112 and 113 represent another FTP PORT command sent from the client to the server.
Packet 114 is the server’s response, advising the client that the new client port number is valid. It
is presumed that none of these packets are actually useful, however, given that packet 111
indicated that the file specified (in the STOR command) cannot be uploaded.
______________________________________________________________________________
______________________________________________________________________________
Packets 115 and 116 represent another attempt by the client to specify a file to be uploaded, in
this case identifying the file as “/home/wkenzie”. Of course, this is not correct, since this is a
directory 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.
______________________________________________________________________________
______________________________________________________________________________
Packet 119 is yet another FTP PORT command sent from the client to the server, specifying yet
another client port to use for the file transfer. Packet 120 responds from the server with an FTP
status 200 reply, again indicating this port is valid.
______________________________________________________________________________
______________________________________________________________________________
Packets 121 and 122 is shown to be the 3rd attempt by the client at getting the STOR command
right.
______________________________________________________________________________
______________________________________________________________________________
Packets 123, 124 and 126 show another 3-way TCP connection established between the server
FTP data port 20 and client port 46292, as specified in the client’s last PORT packet sent in packet
119. The TCP (relative) sequence number in packet shown below is again 0, indicating, along with
the SYN flag, that this is to be a new connection. Packet 124 is the TCP SYN-ACK reply from the
client, and packet 126 is the server’s TCP ACK completing the 3-way handshake.
______________________________________________________________________________
______________________________________________________________________________
Packets 125 and 127 show the server’s response to the client’s FTP STOR command sent in packet
122: first a TCP ACK packet, and then a TCP PSH-ACK packet with encapsulated FTP status 150
record advising the client that the STOR command was valid, and a connection to client port
46292 (as specified by the client in packet 119) will now be attempted. Packet 127 is another
packet received out of sequence, because the connection it is referring to has already been made
by packet 126.
______________________________________________________________________________
______________________________________________________________________________
Packet 128 is a relative milestone in the FTP protocol being negotiated here, as it represents the
first packet that actually sends data from the client to the server. It has a (relative) sequence
number of 1, as shown below. It is being sent (uploaded) from client port 46292 to server port
20, in 1448 byte chunks. This quantity 1448 is set by the limit of 1500-byte packets (which is
1514 with the link-layer header included), minus the 20-byte IP header, minus the 32-byte TCP
header, which is 1500 minus 52 bytes of header data.
______________________________________________________________________________
______________________________________________________________________________
Packet 128 has the FTP data encapsulated as a TCP payload as shown below. Note that the first
few characters of the data are !@#$%\r\n which represents the first record in the Wordlist.txt file
as shown in the image below the packet capture data, with the \r\n being “new line” and “carriage
return” characters to mark the end of a record/line.
______________________________________________________________________________
______________________________________________________________________________
Packets 128, 129, and 130 are all sent by the client one after another, without pause for an ACK
from 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, plus
another 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 of
1500 bytes each, the client is effectively sending 4500 bytes of the 5888 advertised window buffer
size 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 server’s initial
advertised window size limiting the client to sending 3 packets at a time.
______________________________________________________________________________
______________________________________________________________________________
Packet 131 is a TCP ACK packet sent from the client in response to the server’s packet 127 FTP
status 150 response. The TCP (relative) sequence number here is 264, which represents the 33
bytes sent in the most recently sent on this connection packet 122, plus the sequence number of
that packet, 231. The acknowledgement number here is 815, which represents the 30 bytes
received in the most recently received on this connection packet 127, plus the sequence number
of that packet, 785.
______________________________________________________________________________
______________________________________________________________________________
Packet 132 (shown below at 21:21:33.585024) begins a series of similar packets, with a TCP ACK
from the server, followed by 2 or 3 or 4 FTP-DATA packets from the client to the server. This
pattern of packets continues for about 33 seconds, until the last 100 bytes of the file are uploaded
from the client to the server in packet 3992 at 21:22:06.605603 (shown on the next page).
______________________________________________________________________________
______________________________________________________________________________
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 complete
as far as the client is concerned. Packet 4032 (shown on the next page) is a TCP ACK from the
server to packet 3992.
______________________________________________________________________________
______________________________________________________________________________
Packet 4032 shown below is the server’s TCP ACK to packet 3992 from the client. Note that it is
still showing as (relative) sequence number 1. Note also that the (server-side) TCP window size
has increased to 206,848 by this point.
______________________________________________________________________________
______________________________________________________________________________
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 advising
the server it was closing its side of the TCP connection. Packet 4034 finishes the TCP connection
shutdown with an ACK packet sent to the server, and the client port 46292 to server port 20
connection is not seen in any further packets after this.
______________________________________________________________________________
______________________________________________________________________________
Further to the FTP protocol disconnection protocol, packet 4035 from the server’s control port 21
is seen below advising the client in an FTP status 226 record that the file upload has been
completed successfully, and the data port connection is being closed. This packet 4035 appears to
be out of sequence, since the data port connection has already been closed at this point. Note the
FTP status 226 record also gives the file transfer time measured as 33.766 seconds, and the
average transfer rate as 99.96 Kbytes/s.
______________________________________________________________________________
______________________________________________________________________________
Packet 4036 sends a TCP ACK to the server’s packet 4035, and then packet 4037 shown below is
seen 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 the
server in packet 4039, a TCP FIN-ACK from the server in packet 4040 to indicate shutdown of its
side of the server port 21 to client port 46485 connection, a TCP ACK from the client in packet
4041 to the server’s packet 4039 FTP status 221, a TCP FIN-ACK from the client in packet 4042 to
advise the server its side of the TCP connection is closed, and lastly in packet 4043 the server
sends a TCP ACK to the client in response to packet 4042.
______________________________________________________________________________
______________________________________________________________________________
Looking at the Time/Sequence Graph generated by Wireshark[8] for this file upload, as shown
below, it appears that there was a very steady transfer of file packets from the client to the
server.
______________________________________________________________________________
______________________________________________________________________________
As a counter-point to the apparently-steady Time/Sequence graph however, the equivalent

Throughput Graph shows there were significant variations in the amount of data being uploaded
at any given time. Specifically there were 6 steep declines in throughput, demonstrating the
dynamic nature of TCP communication as it self-adjusts to various conditions affecting
throughput, based on its flow control and congestion control algorithms.
______________________________________________________________________________
______________________________________________________________________________
The RTT graph for this TCP transmission also clearly shows this dynamic nature of TCP
communication. As the round-trip times increase to about the 1.3 second mark, TCP’s congestion
avoidance mechanisms kick in to limit the amount of slowdown in packet transmissions, and to
keep the packets flowing, as clearly demonstrated in the Time/Sequence graph above.
______________________________________________________________________________
______________________________________________________________________________
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 ACK’s of packet 753;

Packet 757 TCP Retransmission;
Packet 835 TCP Window update.
1 duplicate ACK of packet 850;
Packet 1096 TCP Fast Retransmission;
______________________________________________________________________________
______________________________________________________________________________
In reviewing the variety of server-side TCP window sizes, a spreadsheet was created showing the
window 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.pdf file on the accompanying DVD, as
well as the fp1_filtered_server_window_sizes.xlsx spreadsheet itself. It shows the window size
starting 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 at
packet 756. The first reductions in window size start appearing at packet 830. The right-side
“Increase” column tracks the changes in server-side windows size from packet to packet.
______________________________________________________________________________
______________________________________________________________________________
Packet 753 at the 5.729 second mark (shown below) is where the first instance of packet
transmissions problems shows up. Actually, packet 753 had no problems, and was simply a TCP
ACK sent from the server to the client. However, packet 756 is a Duplicate ACK, sent just 0.013
seconds after packet 753, and then repeated/duplicated again 44 more times, over the next 0.613
seconds up to and including packet 829. Why the duplicate ACKs? Most likely because the server
has encountered an out-of-order packet, and must therefore tell the client immediately, because
TCP cannot determine if this out-of-order condition is perhaps caused by a lost packet that must
be re-sent.
The TCP retransmissions starting at packet 757 and ending with packet 828 confirm that this is
likely what is occurring here.
______________________________________________________________________________
______________________________________________________________________________
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 specified
in packet 756. So the TCP duplicate ACK in packet 756 is telling the client to go back and resend
packet 674, which the client immediately does in packet 757. Packet 674 is shown on the next
page, and is identified by the (relative) sequence number 531,233 that it used.
______________________________________________________________________________
______________________________________________________________________________
Packet 674 is shown below, which is the first packet retransmitted (in packet 757). If we had
captured the TCP packets for this transmission on the server as well as on the client, we would
likely have been able to know whether packet 674 had been lost, or merely received out-of-order.
______________________________________________________________________________
______________________________________________________________________________
This duplicate ACK and subsequent retransmission condition appears a number of times during the
life of this file upload.
In the case of there being at least 36 duplicate ACKs sent from the server (the “major” duplicate
ACK 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 of
the file upload, as shown below. The client waited in this case for 3 duplicate ACK’s, before
initiating a Fast Retransmit, whereas at packet 753 it did not. Fast Retransmission was the client’s
response in 5 of the 7 major duplicate ACK conditions, and it is thus believed that the client TCP
stack does not always wait for 3 duplicate ACKs before initiating a fast retransmission.
______________________________________________________________________________
______________________________________________________________________________
The 7 major TCP duplicate ACK conditions are summarized below, with the “Recovery Seconds”
column representing the amount of time elapsed between the first duplicate ACK packet sent by
the server, to the last duplicate ACK packet after which the out-of-order or lost packet condition
was resolved.
Packet No. ACK No. of No. of Last Recovery

Duplicated Number Duplicate ACKs Retransmissions Packet Seconds
753 531,233 45 12 829 0.627
1087 786,081 47 3 1170 0.651
1730 1359,489 42 2 1803 0.586
2274 1854,705 44 1 2350 0.615
3022 2542,505 47 4 3097 0.656
3417 2878,441 45 3 3497 0.641
3994 3402,617 36 1 4031 0.491
There is a remarkable amount of consistency between each of these 7 instances, which leads one
to speculate that this condition was either not caused by a random lost packet, or that the
efficiency of recovery by TCP from a lost packet or out-of-order packet is relatively constant and
predictable. The following Wireshark[8] graph is quite interesting in this regard.
______________________________________________________________________________
______________________________________________________________________________
The remaining “minor” TCP duplicate ACK conditions are summarized as follows:
Packet No. ACK No. of No. of Last Recovery

Duplicated Number Duplicate ACKs Retransmissions Packet Seconds
831 539,921 2 0 833 0.028
835 550,057 2 0 839 0.029
842 560,193 2 0 846 0.028
850 567,433 1 0 852 0.015
856 574,673 1 0 858 0.013
862 581,913 1 0 864 0.015
868 589,153 1 0 870 0.013
1174 816,489 8 2 1190 0.113
1194 838,209 9 0 1212 0.125
1216 857,033 10 0 1236 0.141
3099 2567,121 7 0 3111 0.085
3117 2588,841 7 0 3131 0.096
3135 2610,561 4 0 3143 0.068
3499 2903,057 7 0 3513 0.108
3517 2927,673 9 0 3533 0.108
There is likely a significant difference in whatever condition caused these “minor” duplicate ACKs
compared to the previous “major” condition. Further research using both client and server packet
capture should provide more information to help identify what this difference might be.
______________________________________________________________________________
______________________________________________________________________________
(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 client
console running in VMware[10] Workstation VM on Microsoft Windows[11] 7 Ultimate desktop, with
command-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 1
each for control and data communications. This was done to allow it to be used through the Tor
network. The –v argument passed to ftp enables “verbose” mode. sudo, of course, is the Ubuntu
“super user do it” command. usewithtor is a shell wrapper that forces ftp to use the locally
installed and running Tor instance on local port 9050.
The accompanying fp2_filtered.pcap and fp2_original.pcap files, which were captured on the
client, does not show any of the normal TCP or FTP protocol information because the Tor network
encrypts all of its packets.
Note that the above snapshot shows the file upload completed in 172.221 seconds, at 19.6
Kbytes/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 Xubuntu
instance as in Upload 1.
______________________________________________________________________________
______________________________________________________________________________
The following screen shows the man page for the usewithtor program wrapper:
______________________________________________________________________________
______________________________________________________________________________
The following screen shows the Ubuntu configuration setting to force all locally transmitted
packets to enter the Tor network at local port 9050:
______________________________________________________________________________
______________________________________________________________________________
The Time/Sequence Graph generated by Wireshark[8] for Upload 2 is shown below. It appears that
there was a clear TCP “fast start” phase, followed by a relatively steady transfer of file packets
from the client to the server. This is discussed further in the Summaries and Conclusions section
of this assignment.
______________________________________________________________________________
______________________________________________________________________________
The Upload 2 Throughput Graph generated by Wireshark[8] is shown below, and discussed in the
Summaries and Conclusions section of this assignment.
______________________________________________________________________________
______________________________________________________________________________
The corresponding RTT Graph for Upload 2 is shown below, and also discussed in the Summaries
and Conclusions section of this assignment.
______________________________________________________________________________
______________________________________________________________________________
(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 console
running in VMware[10] Workstation VM on Microsoft Windows[11] 7 Ultimate desktop, with
command-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 resultant
fp3_filtered.pcap and fp3_original.pcap files are included on the accompanying DVD.
______________________________________________________________________________
______________________________________________________________________________
The following screen shows the Ubuntu configuration setting to make a direct connection to the
Internet, rather than using a locally running proxy:
______________________________________________________________________________
______________________________________________________________________________
The Time/Sequence Graph generated by Wireshark[8] for Upload 3 is shown below. Similar to
Upload 2, there appears to be a clear TCP “fast start” phase, followed by a relatively steady
transfer of file packets from the client to the server. This is discussed further in the Summaries
and Conclusions section of this assignment.
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
The RTT Graph for Upload 3 is shown below, and also discussed in the Summaries and
Conclusions section of this assignment.
______________________________________________________________________________
______________________________________________________________________________
A spreadsheet file fp3_filtered.xlsx (included on the accompanying DVD) - which is sorted by the
“Info” field primarily, and by the Packet “No.” field secondarily – is an attempt to understand the
above graphs. One thing of interest is the large number of “TCP ZeroWindow” and “TCP Window
Update” packets. There are fully 1214 TCP ZeroWindow packets sent from the server to the client,
starting at packet 374 and ending at 5923, indicating the server is telling the client to stop
sending packets. The distribution of ZeroWindow packets is shown in the graph below.
The reason for all these ZeroWindow packets is not understood at this time. It is especially
unusual given that the window size communicated by the server to the client was never very
large. Further research and analysis will be required to determine reason the Ubuntu Desktop VM
client was the only one of the 5 uploads which exhibited this behaviour.
______________________________________________________________________________
______________________________________________________________________________
(4) Upload from Windows 7 Ultimate desktop client
FileZilla[6] version 3.3.4.1 was used for Upload 4 from a Windows[11] 7 Ultimate desktop client.
______________________________________________________________________________
______________________________________________________________________________
The following snapshot shows the successful transfer of the Wordlist.txt file to the server.
Wireshark[8] was running simultaneously on the same Windows 7 client, and the resultant
fp4_filtered.pcap and fp4_original.pcap files are included on the accompanying DVD.
______________________________________________________________________________
______________________________________________________________________________
The Time/Sequence Graph generated by Wireshark[8] for Upload 4 is shown below. This is
discussed further in the Summaries and Conclusions section of this assignment.
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
Some TCP Duplicate ACK packets were sent from the server to the client in Upload 4, as indicated
below, similar to what was observed in Upload 1. Again, these were likely caused by out-of-order
packets received by the server, which must tell the client immediately, because TCP cannot
determine if this out-of-order condition is perhaps caused by a lost packet that must be re-sent.
______________________________________________________________________________
______________________________________________________________________________
There were also a few TCP retransmission packets sent from the client to the server in Upload 4,
as shown below:
______________________________________________________________________________
______________________________________________________________________________
(5) Upload from Ubuntu Internet Server
This file upload was done from a dedicated Internet server running Ubuntu[9] 8.10 Server, with
command-line ftp, as shown below.
The transmission packets in this case were captured using TShark[12] running simultaneous to the
ftp upload, whereas the previous 4 uploads were captured using a simultaneous instance of
Wireshark[8]. The source server in this case was very busy, running multiple thousands of other
processes at the time of the upload.
Note the file upload here was completed in just 1.75 seconds, at a throughput over 19 times
greater than in Uploads 1, 3 and 4.
______________________________________________________________________________
______________________________________________________________________________
TShark[12] was started on the source server as shown below for Upload 5. The
fp8_00001_20101123153252 file created here by TShark was later renamed to fp5_original.pcap
and is included on the accompanying DVD along with a filtered version fp5_filtered.pcap.
______________________________________________________________________________
______________________________________________________________________________
The Time/Sequence Graph generated by Wireshark[8] from the fp5_filtered.pcap file for Upload 5
is shown below. This is discussed further in the Summaries and Conclusions section of this
assignment.
______________________________________________________________________________
______________________________________________________________________________
The Upload 5 Throughput Graph generated by Wireshark[8] from the fp5_filtered.pcap file is shown
below, and discussed in the Summaries and Conclusions section of this assignment.
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
Summaries and Conclusions
The Time/Sequence graphs for each of the five uploads are shown below.
Upload 1 from Xubuntu desktop.
This is essentially identical to

uploads 3 and 4.
Upload 2 from Ubuntu VM through

Tor network.
This shows a slower upload (about

200 seconds) and a faster start to
the upload, than the other uploads,
but much the same in terms of
progression.
______________________________________________________________________________
______________________________________________________________________________
Upload 3 from Ubuntu VM.
This is essentially identical to the

Time/Sequence Graphs for uploads
1 and 4, other than the short TCP
fast start phase shown here right at
the beginning.
Upload 4 from Windows 7 desktop

using FileZilla.
This is essentially identical to the

Time/Sequence Graphs for
uploads 1 and 3.
______________________________________________________________________________
______________________________________________________________________________
Upload 5 from one Internet

server to another.
This is the most fascinating of

the Time/Sequence graphs.
There are dramatic, nearly
vertical sections of the graph,
each followed by a relatively
equal pause period of about 0.1
seconds. Each of the vertical
sections is also longer than the
previous, representing
progressively larger bursts of
data being sent to the server.
The conclusion drawn from these Time/Sequence graphs is that the conditions under which these
file uploads were done allowed for a fairly steady transfer of data over time. The last upload,
however, was sufficiently fast to more clearly demonstrate that TCP dynamically adjusts its
behaviour as it progresses with packet transmission.
______________________________________________________________________________
______________________________________________________________________________
The Throughput graphs for each of the five uploads are shown below.
Upload 1 from Xubuntu

desktop.
This shows far more

information than the
Time/Sequence graph for the
same upload. TCP fast start is
clearly shown in the first 1
second, followed by a series of
7 separate declines and
increases in throughput. Most
of the throughput rate,
however, is surprisingly
constant at 2 distinct rates of
about 102KB/s and of about
115KB/s.
Upload 2 from Ubuntu VM

through Tor network.
The TCP fast start brings

throughput up to about
6.25KB/s but most of the
upload is done at a more
modest throughput between an
upper limit of 1.5KB/s and a
scattering of 0.4KB/s to
1.0KB/s. Of additional interest
is the fact that throughput
drops to 0 at least 25 different
times. Overall though, this is a
somewhat “bland” picture of
throughput data when
compared to the other 4
uploads.
______________________________________________________________________________
______________________________________________________________________________
This throughput graph is likely

skewed by the huge initial
increase in throughput to the point
of losing most detail for the bulk
of the upload time period.
Throughput appears to reach over
13MB/s within the first 0.25
second or so, which leaves little
differentiating detail that can be
shown on this graph at this scale
for the remaining 33+ seconds.
Upload 4 from Windows 7 desktop

using FileZilla.
Being the only upload from a

Windows client, the throughput
“fingerprint” here is significantly
different from each of the other
uploads.
______________________________________________________________________________
______________________________________________________________________________

server to another.
This is another very

distinctive graph, with 6 near-
vertical sets of data points,
separated by roughly equal
pauses in throughput of about
0.1 seconds each.
The conclusion drawn from these Throughput graphs is that, quite surprisingly, there is almost no
similarity between any of the 5 graphs. The Windows 7 TCP stack in Upload 4 produced a
significantly different data set from all the other uploads. The Tor network in Upload 2 did the
same, producing a significantly different data set from all the other uploads. Upload 3 from the
Ubuntu VM was not clear enough to learn much, other than it produced by far the largest increase
in throughput in the TCP fast start phase. The Xubuntu TCP stack in Upload 1 produced a
throughput fingerprint that was perhaps the most expected, with clear indications of TCP flow
control at work. Upload 5 from server to server also likely showed TCP flow control at work, but
it’s “burst-y” nature, and regular pauses between bursts is somewhat surprising.
______________________________________________________________________________
______________________________________________________________________________
The RTT graphs for each of the five uploads are shown below.
Upload 1 from Xubuntu desktop.
These RTT values clearly show

the dynamic flow control
adjustments made by the TCP
protocol at 7 different times
during the upload. When the RTT
value reached about 1.3 seconds,
the packet transmissions were
adjusted each time to quickly
bring down the RTT value to a
range of 0.3 to 0.4 seconds.
Upload 2 from Ubuntu VM

through Tor network.
The fact that the RTT values in

this upload are markedly smaller
than in upload 1, seems to
indicate that the Tor network
must be supplying RTT values to
the originating source of the
packets being sent, rather than
the intended destination. The fact
that the RTT values are
distributed in a tight range of
only 2 different values seems to
indicate that the Tor network
software is determining these
values, rather than the Internet
at large.
______________________________________________________________________________
______________________________________________________________________________
This is another remarkable

graph, in that almost all RTT
values - other than just 8
individual RTT values – are
clustered just above zero! It is
not immediately obvious what
has caused such an usual
distribution of RTT values for
this upload.
Upload 4 from Windows 7

desktop using FileZilla.
The fingerprint for these RTT

values is somewhat similar to
upload 1, but the increased
fuzziness/distribution of values
compared to upload 1 is likely a
fingerprint of the Windows TCP
stack, since this signature/
pattern also showed up in the
Throughput graph for Upload 4.
______________________________________________________________________________
______________________________________________________________________________

server to another.
These RTT values show little

variation for the first half of the
upload, but then show
unexpected values for the
remainder of the upload.
The conclusion drawn from these RTT graphs is that - as for the Throughput graphs shown
previously - there is a remarkable dissimilarity between the 5 graphs. The Windows 7 TCP stack in
Upload 4 produced a data set similar to Upload 1, but different from all the other uploads. The Tor
network in Upload 2 produced a significantly different data set from all the other uploads. Upload
3 from the Ubuntu VM was not clear enough to learn much, because there was such a large range
of values between the majority of RTT’s and the 8 other RTT’s that were so much larger in value.
The Xubuntu TCP stack in Upload 1 produced a throughput fingerprint that was perhaps the most
expected, with clear indications of TCP fast start, flow control, and congestion control. Upload 5
from server to server showed the most difficult to comprehend values, and more research would
be required to understand the reasons these values were found.
______________________________________________________________________________
______________________________________________________________________________
Bibliography
[1] Kurose, James F. and Ross, Keith W. Computer Networking : a Top-Down Approach. 5th
edition. 2010. Addison-Wesley. Boston, MA. ISBN 0-13-607967-9.
[2] Heywood, Drew and Ahmad, Zubair. 2001. Drew Heywood’s Windows 2000 Network Services.
Sams Publishing, Indianapolis, IN. p. 53. ISBN 0672317419.
[3] RFC 959. File Transfer Protocol (FTP). Reference found on Internet “ietf.org” site, at
http://tools.ietf.org/html/rfc959 on November 25, 2010.
[4] Sinha, Shweta. A TCP Tutorial. 1998. Reference found on “ssfnet.org” Internet site, at
http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html on November 28, 2010.
[5] The Tor Project: Anonymity Online. Reference found on “torproject.org” Internet site at
https://www.torproject.org/ on November 28, 2010.
[6] FileZilla: The free FTP solution. Reference found on “filezilla-project.org” Internet site at
http://filezilla-project.org/ on December 2, 2010.
[7] Xubuntu: Linux for human beings. Reference found on “xubuntu.org” Internet site at
http://www.xubuntu.org/about/ on December 2, 2010.
[8] Wireshark: the world’s foremost network protocol analyzer. Reference found on
“wireshark.org” Internet site at http://www.wireshark.org/ on December 2, 2010.
[9] Ubuntu Server Edition. Reference found on “ubuntu.com” Internet site at

http://www.ubuntu.com/server/ on December 2, 2010.
[10] VMware Workstation. Reference found on “vmware.com” Internet site at

http://www.vmware.com/products/workstation/ on December 2, 2010.
[11] Get to know Windows 7. Reference found on “microsoft.com” Internet site at

http://www.microsoft.com/windows/windows-7/ on December 2, 2010.
[12] TShark – Dump and analyze network traffic. Reference found on “wireshark.org” Internet site
at http://www.wireshark.org/docs/man-pages/tshark.html on December 2, 2010.
[13] Pure-FTPd: A secure FTP daemon. Reference found on “pureftpd.org” Internet site at
http://www.purefptd.org/project/pure-ftpd on December 2, 2010.
[14] Raw FTP Command List. Reference found on Internet “nsftools.com” site, at
http://www.nsftools.com/tips/RawFTP.htm on December 2, 2010.
______________________________________________________________________________
______________________________________________________________________________
Credits
Wireshark is a registered trademark of the Wireshark Foundation.

Xubuntu is a registered trademark of Canonical Ltd.
Ubuntu is a registered trademark of Canonical Ltd.
VMware is a registered trademark of VMware Inc.
Windows is a registered trademark of Microsoft Corporation.
Linux is a registered trademark of Linus Torvalds.
______________________________________________________________________________

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

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

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

Загружено:

Авторское право:

Доступные форматы

BCIT Computing and Information Technology

COMP 7005 Data Communication Principles

(1) Upload from Xubuntu Desktop client ......................................................... page 2

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

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

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

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

(1) Upload from Xubuntu Desktop client

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

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

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

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

As a counter-point to the apparently-steady Time/Sequence graph however, the equivalent

45 duplicate ACK’s of packet 753;

Packet No. ACK No. of No. of Last Recovery

Packet No. ACK No. of No. of Last Recovery

(2) Upload from Ubuntu Desktop VM client through Tor

(4) Upload from Windows 7 Ultimate desktop client

(5) Upload from Ubuntu Internet Server

Summaries and Conclusions

Upload 1 from Xubuntu desktop.

This is essentially identical to

Upload 2 from Ubuntu VM through

This shows a slower upload (about

Upload 3 from Ubuntu VM.

This is essentially identical to the

Upload 4 from Windows 7 desktop

This is essentially identical to the

Upload 5 from one Internet

This is the most fascinating of

Upload 1 from Xubuntu

This shows far more

Upload 2 from Ubuntu VM

The TCP fast start brings

Upload 3 from Ubuntu VM.

This throughput graph is likely

Upload 4 from Windows 7 desktop

Being the only upload from a

Upload 5 from one Internet

This is another very

Upload 1 from Xubuntu desktop.

These RTT values clearly show

Upload 2 from Ubuntu VM

The fact that the RTT values in

Upload 3 from Ubuntu VM.

This is another remarkable

Upload 4 from Windows 7

The fingerprint for these RTT

Upload 5 from one Internet

These RTT values show little

[9] Ubuntu Server Edition. Reference found on “ubuntu.com” Internet site at

[10] VMware Workstation. Reference found on “vmware.com” Internet site at

[11] Get to know Windows 7. Reference found on “microsoft.com” Internet site at

Wireshark is a registered trademark of the Wireshark Foundation.

Вам также может понравиться