Yu Cheng (Jade)
ICS 351
Lab Report 5 part 1
November 02, 2008
[Exercise 1A]
We connected the ethernet interfaces of the PCs. We used the following commands
to configure the IP addresses and the interfaces on the PCs:
on PC1: `ifconfig eth0 10.0.1.11/24`
on PC1: `ifconfig eth1 10.0.5.11/24`
on PC2: `ifconfig eth0 10.0.2.22/24`
on PC2: `ifconfig eth1 10.0.5.22/24`
on PC3: `ifconfig eth0 10.0.1.33/24`
on PC3: `ifconfig eth1 10.0.2.33/24`
PC1 and PC2 were used as the hosts. PC3 was used as the IP router. We used the
following commands to disable the IP forwarding on PC1 and PC2, and enable the
IP forwarding on PC3:
on PC1: `echo "0" > /proc/sys/net/ipv4/ip_forward`
on PC2: `echo "0" > /proc/sys/net/ipv4/ip_forward`
on PC3: `echo "1" > /proc/sys/net/ipv4/ip_forward`
We then added PC3 as the default IP router for both PC1 and PC2:
on PC1: `route add default gw 10.0.1.33`
on PC2: `route add default gw 10.0.2.33`
We issued ping commands, `ping 10.0.2.22` and `ping 10.0.5.22` from PC1 to both
of the interfaces on PC2 to verify the connection. We observed successful
pinging.
[Exercise 1B]
We started the wireshark on PC1 interface 1 to capture the traffic between PC1
and PC2. We set a caputure filter as `host 10.0.5.22`. Then we started the
ttcp receiving and sending using commands:
on PC2: `ttcp -rs -l1024 -n10 -p4444 -u`
on PC1: `ttcp -ts -l1024 -n10 -p4444 -u 10.0.5.22`
In these commands, -t specified the transmit mode, -r specified the receive
mode, -u specified to use UDP intead of TCP, -l here specified the number of
data bytes in UDP datagram, -p specifies the port number to send to or liste on.
Question 3-a
There were 16 packets exchanged. Ten of them carried 1024 bytes of data. Six
of them carried 4 bytes of data. There were 10 UDP datagrams sent because we
specified the length of a datagram as 1024 bytes. Therefore, one packet was
transmitted for each UDP datagram. The size of the UDP payload of these packets
was 1024.
Question 3-b
The total number of bytes transmitted can be calculated. There were 10 packets
with a frame length of 1066 bytes. There were 6 packets with a frame length of
46 bytes. The total number of bytes transmitted was 1066 * 10 + 46 * 6 = 10936
bytes. The amount of application data were the 10 UDP datagram that were sent.
That was 10240 bytes.
Question 3-c
In the UDP headers, we observed that the following fields did not change in
different packets.
--------------------------------------------------------------------------------
Source: 10.0.5.11 (10.0.5.11)
Destination: 10.0.5.22 (10.0.5.22)
User Datagram Protocol, Src Port: 54687 (54687), Dst Port: 4444 (4444)
Source port: 54687 (54687)
Destination port: 4444 (4444)
--------------------------------------------------------------------------------
Question 3-d
We observed that the source port number in our first run was 54687. In order to
determine if this was randomly selected, we redid the ttcp transmission a second
time. This time, we observed another source port number, which was 48264. So,
the source port number that the sender, PC2, sent packets to the receiver, PC1,
was randomly generated.
We then stopped the wireshark caputuring on PC1 and saved the caputured traffic
with the detailed information of packets as ex1b-4.txt.
[Exercise 1C]
We started the wireshark on PC1 interface 1 again to caputure traffic between
PC1 and PC2 for this exercise. We also set a capture filter `host 10.0.5.22`.
We then started another ttcp transmission using TCP. We used commands:
on PC2: ttcp -rs -l1024 -n10 -p4444
on PC1: ttcp -rs -l1024 -n10 -p4444 -D 10.0.5.22
In these commands, we didn't specify the protocol type because ttcp use TCP as
the default protocol to transmit data. -l indicated the length of the
application data blocks that are passed to TCP in bytes. -D disabled buffering
of data in TCP and forces immediate transmission of the data at the ttcp sender.
Question 3-a
There were intotal 22 packets exchanged. They included a [SYN], [SYN, ACK], and
[ACK] packet at the begining as the three way handshak to build the conncetion
and a [FIN], [FIN, ACK], and [ACK] packet at the end to terminate the
connection.
There were 8 packets that carried a payload. The TCP application size was at
first 1024 bytes for the first 2 packets. It increased to 1448 bytes for the
following 5 packets, and then it dropped to 952 bytes for the last packet.
This could be explained by Nagle's algorithm. More than one outgoing messages
were sent as one packet. The sender PC1 kept buffering its output until it has
a full packet's worth of output, and then output can be sent all at once. The
default MTU must be 1500, so 1448 bytes must be the largest application segment
TCP can send.
Question 3-b
The the relative sequence numbers ranged from 0 to 10242. The actual sequence
numbers ranged from da,fa,27,e9 to da,fa,4f,eb. We learned about this by
highlighting the sequence number and looked them up from the hex dump.
Question 3-c
There were 12 packets transmitted by PC1, the sender, and 10 packets were
transmitted by PC2, the receiver.
Question 3-d
There were 14 packets that did not carry a payload. They included the first
three and the last three packets that established and terminated the connection.
There are 8 more [ACK] packets during the application data transmission.
Question 3-e
The first three packets:
74 * 2 + 66 = 214
The application data transmitted:
1092 * 2 + 1514 * 5 + 1018 = 10772
The last three packets:
66 * 3 = 198
The [ACK] packets during data transmission:
66 * 8 = 528
The total was:
214 + 10772 + 198 + 528 = 11712
The aaplication data transmitted was 10772
Question 3-f
All of the TCP headers contain certain kinds of flags. We observed packets with
[SYN], [SYN, ACK], [ACK], [FIN], [FIN, ACK], [PSH, ACK] flags or flag
combinations.
We stopped the wireshark and saved the output with detailed packets' information
as ex1c-4.txt
Question 2 (Qeustion 1 is anwered in the previous section)
UDP transmitted 1024 * 10 = 10240 bytes of applicaiton data and 10936 bytes of
data in total. TCP transmitted 10772 bytes of application data and 11712 bytes
of data intotal.
Question 3
The biggest UDP data gram was 1024 bytes as we set in the command. The biggest
TCP segment was 1448 bytes because TCP uses Nagle's algorithm to send more than
one packets at a time. The smaller ones were appended on the TCP data
transmission packets. TCP has a larger segment than UDP's largest data gram.
[Exercise 2]
The file with large contents was already created. It was in directory:
/var/lib/tftpboot/. We started the wireshark on PC1 interface 1 to caputure the
traffic between PC1 and PC2. We set the capture filter as `host 10.0.2.55`. We
changed the current directory to /labdata, and started ftp on PC2 using command,
`ftp 10.0.5.11`. We transfered the file from PC1 to directory /labdata on PC2:
ftp> cd /var/lib/tftpboot
ftp> get large.d
ftp> quit
We saved the output as ex2-3.txt. The contents were as below:
--------------------------------------------------------------------------------
ftp> cd /var/lib/tftpboot
250 Directory successfully changed.
ftp> get large.d
local: large.d remote: large.d
227 Entering Passive Mode (10,0,5,11,65,21).
150 Opening BINARY mode data connection for large.d (966072 bytes).
226 File send OK.
966072 bytes received in 0.0981 secs (9845.42 Kbytes/sec)
ftp> quit
221 Goodbye.
--------------------------------------------------------------------------------
We did the similar operation using tftp. We started the tftp on PC2 usnig
command `tftp 10.0.5.11`. We transferred the file using commands:
tftp> get large.d
tftp> quit
We saved the output as ex2-4.txt. The contents were (basically nothing):
--------------------------------------------------------------------------------
[root@PC2 labdata]# tftp 10.0.5.11
tftp> get large.d
tftp> quit
[root@PC2 labdata]#
--------------------------------------------------------------------------------
Question 3-a
We saved the first ftp data transmission packet as ex2-5ftp-1.txt, the last ftp
transmission packet as ex2-5ftp-2.txt.
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
50 115.328277 10.0.5.11 10.0.5.22 FTP
Info
Response: 150 Opening BINARY mode data connection for large.d (966072 bytes).
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
1085 115.437770 10.0.5.11 10.0.5.22 FTP
Info
Response: 226 File send OK.
--------------------------------------------------------------------------------
By observing the timestamps of these two packets, we learned that the time
interval was:
115.437770 - 115.328277 = 0.109493 sec
We saved the first tftp data transmission packet as ex2-5tftp-1.txt, the last
tftp transmission packet as ex2-5tftp-2.txt.
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
1093 258.194495 10.0.5.22 10.0.5.11 TFTP
Info
Read Request, File: large.d\000, Transfer type: netascii\000
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
4886 258.814023 10.0.5.11 10.0.5.22 TFTP
Info
Response: Data Packet, Block: 1897 (last)
--------------------------------------------------------------------------------
By observing the timestamps of these two packets, we learned that the time
interval was:
258.814023 - 258.194495 = 0.619528 sec
By comparing these two time intervals, we learned that ftp is significantly
faster than tftp. As we know, ftp uses TCP and tftp uses UDP, we learned that
TCP is considerably faster than UDP. This is due to the fact that TCP
establishes a stable connection between the server and the client but UDP
doesn't. Therefore tftp has to request for ACK for each transmission.
Question 3-b
The connection information was contained in the Internet Protocol section.
The port number for the client to listen on is 21. The destination port was
randomly choosen. The source, the server, was 10.0.5.11, PC1, and the
destination, the client, was 10.0.5.22, PC2.
--------------------------------------------------------------------------------
Internet Protocol, Src: 10.0.5.11 (10.0.5.11), Dst: 10.0.5.22 (10.0.5.22)
:
Protocol: TCP (0x06)
Header checksum: 0xca8b [correct]
[Good: True]
[Bad : False]
Source: 10.0.5.11 (10.0.5.11)
Destination: 10.0.5.22 (10.0.5.22)
Transmission Control Protocol, Src Port: 21 (21), Dst Port: 42318 (42318),
Seq: 211, Ack: 83, Len: 69
Source port: 21 (21)
Destination port: 42318 (42318)
--------------------------------------------------------------------------------
[Exercise 3A]
We started wireshark on PC1 interface 0 and PC2 interface 0 with no filter. We
initially used the following UDP datagram size for the transmission:
on PC2: `ttcp -rs -l1024 -n12 -p4444 -u`
on PC1: `ttcp -ts -l1024 -n12 -p4444 -u 10.0.2.22`
This UDP datagram size went through the network without any fragmentation. We
observed only the UDP packets. Then we increased the receiving end with a large
UDP datagram expectation size to ensure the fagmentation was coursed by the
sending end.
By observing the previous wireshark traffic we saw that the length of one UDP
packet was 1480 bytes. We then set the it tobe slightly larger:
on PC1: `ttcp -ts -l1490 -n12 -p4444 -u 10.0.2.22`
We observed the IP fragmentation after this modification. We saved the IP
fragmentation packet as ex3a-5-1.txt.
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
183 229.729957 10.0.1.11 10.0.2.22 IP
Info
Fragmented IP protocol (proto=UDP 0x11, off=0) [Reassembled in #184]
--------------------------------------------------------------------------------
We saved one UDP packet that was not fragmentted as ex3a-5-2.txt, and one UDP
packet that was fragmentted as ex3a-5-3.txt. They look about the same.
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
182 229.729589 10.0.1.11 10.0.2.22 UDP
Info
Source port: 47870 Destination port: 4444
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
213 229.730651 10.0.1.11 10.0.2.22 UDP
Info
Source port: 47870 Destination port: 4444
--------------------------------------------------------------------------------
Question 4-a
The examct UDP datagram size is 1480 bytes. This was when the fragmentation
started to occur.
Question 4-b
In order to observe the scenario that the UDP datagram was too large for the
system to send, we used command:
on PC1: `ttcp -ts -l1024000 -n12 -p4444 -u 10.0.2.22`
We observed a error message. We reduce the number 10240 by dividing it by two.
We tried quite some times. Eventually, we found the exact size that this
happened. That was 65507.
on PC1: `ttcp -ts -l65507 -n12 -p4444 -u 10.0.2.22` -------> success
on PC1: `ttcp -ts -l65508 -n12 -p4444 -u 10.0.2.22` -------> fail
Question 1
--------------------------------------------------------------------------------
Internet Protocol, Src: 10.0.1.11 (10.0.1.11), Dst: 10.0.2.22 (10.0.2.22)
:
Header length: 20 bytes
:
Identification: 0xa09e (41118)
Flags: 0x02 (More Fragments)
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..1. = More fragments: Set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
:
Source: 10.0.1.11 (10.0.1.11)
Destination: 10.0.2.22 (10.0.2.22)
:
--------------------------------------------------------------------------------
[Exercise 3b]
We used command `ifconfig` to dipaly the MTU for each PC. The values were set
to 1500. We used command `ifconfig eth0 mtu 500` to change the MTU value on PC2
interface 0. We started the wireshark on PC1 interface 0 and PC3 interface 0
with no filter. Then, we started ttcp data transmission between PC1 and PC2
using the following commands:
on PC2: ttcp -rs -l1024 -n2 -p4444
on PC1: ttcp -ts -l1024 -n2 -p4444 -D 10.0.2.22
Question 3-a
No, we didn't observe IP fragmentation, but we observed TCP segmentation. For
communication using TCP, the sender and the receiver negotiate what would be the
proper TCP segment size for data transmission during three way handshake.
In the [SYN] packet (ex3b-3-1.txt) from the server to the client, the server
told the client that it could send with a MSS of 1460. In the [SYN, ACK] packet
(ex3b-3-2.txt) from the client to the server, the client told the server that it
could receive with a MSS of 460. Therefore the TCP transmssion segment size was
settled down with the smaller one, 460. In this setup, the IP router has a
larger MTU than this, so it didn't impair the transmission. So no IP
fragmentation was observered during the transmssion.
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
7 62.662832 10.0.1.11 10.0.2.22 TCP
Info
48748 > 4444 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 ...
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
8 62.663289 10.0.2.22 10.0.1.11 TCP
Info
4444 > 48748 [SYN, ACK] Seq=0 Ack=1 Win=1792 Len=0 MSS=460 ...
--------------------------------------------------------------------------------
Question 3-b
By observing the saved packets, the DF bit was set in the IP datagrams, "Flags:
0x04 (Don't Fragment)". We didn't receive ICMP error message was because the IP
router has a larger MTU than 460 bytes, which was the TCP segment size agreed by
the server, PC1, and the client, PC2, during the three way handshake.
We changed the MTU on PC2 interface 0 back to 1500, and we changed the MTU on
PC3 interface 1 to 500 using command `ifconfig eth1 mtu 500`. We repeated the
data transmission:
on PC2: ttcp -rs -l1024 -n2 -p4444
on PC1: ttcp -ts -l1024 -n2 -p4444 -D 10.0.2.22
Question 5-a
We didn't observe IP fragmentation, instead we observed ICMP error messages sent
from PC3 to PC1. The fragmentation didn't occure becuase the DF bit was set on.
This is the default setting of TCP. No fragmentation during the transmission,
if there is a bottleneck on the way, the packet is dropped and an ICMP error
message notify the sender to send smaller packets and resend the one that was
just dropped.
Question 5-b
The basic procedure of path MTU discovery is simple--send the largest packet
the sender can, and if it won't fit through, some link get back a notification
saying what size will fit. The notifications arrive as ICMP packets known as
"fragmentation needed" ICMPs. The notifications are requested by setting the
"do not fragment" (DF) bit in packets that are sent out. When ICMP error
"fragment needed" messages are generated, the MTU interface that caused the
fragmentation would return and tell what size will fit. We save the ICMP packet
as ex3b-6-icmp.txt.
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
31 617.719356 10.0.1.33 10.0.1.11 ICMP
Info
Destination unreachable (Fragmentation needed)
--------------------------------------------------------------------------------
We also saved one TCP packet before MSS readjusting as ex3b-6tcp-1.txt and one
TCP packet after MSS readjusting as ex3b-6tcp-2.txt. We observed that the frame
length was adjusted from 1024 to 500 to fit the IP router's MTU.
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
28 617.718921 10.0.1.11 10.0.2.22 TCP
Info
59578 > 4444 [PSH, ACK] Seq=1 Ack=1 Win=5856 Len=1024 ...
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
32 617.719434 10.0.1.11 10.0.2.22 TCP
Info
[TCP Out-Of-Order] 59578 > 4444 [ACK] Seq=1 Ack=1 Win=5856 Len=500 ...
--------------------------------------------------------------------------------
[Exercise 4A]
We used command `ifconfig eth# mtu 1500` to change the PCs' setting back to
default. We used command `ifconfig` to verify this change. We then started the
wireshark on PC1 interface 1 with no filter. We established a telnet session
from PC1 to PC2 using command `telnet 10.0.5.22`.
Question 3-a
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
19 60.121971 10.0.5.22 10.0.5.11 TCP
Info
23 > 36862 [FIN, ACK] Seq=135 Ack=160 Win=5792 Len=0 TSV=5933327 TSER=5873244
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
20 60.122243 10.0.5.11 10.0.5.22 TCP
Info
36862 > 23 [FIN, ACK] Seq=160 Ack=136 Win=5856 Len=0 TSV=5933135 TSER=5933327
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
21 60.122395 10.0.5.22 10.0.5.11 TCP
Info
23 > 36862 [ACK] Seq=136 Ack=161 Win=5792 Len=0 TSV=5933328 TSER=5933135
--------------------------------------------------------------------------------
The client here send a [FIN, ACK] packet to request a termination of the
connection, the server send a [FIN, ACK] packet to ack the request. The client
further send a [ACK] packet to notify the it received the ack from the server.
Then the connection between these two were terminated.
Question 3-b
Based on the abstracted discription of the packets, the client started with 135
relative sequence number and the client started with 160 relative sequence
number. We learned about the actual sequence numbers by looking at the hex
dump. The first [FIN, ACK] packet from the client came with a sequence number:
d6,c1,a4,46. The second [FIN, ACK] packet from the server came with a sequece
number: fo,4e,76,69. The third [ACK] packet from the client came with a
sequence number: d6,c1,a4,47. The sequence numbers used by the server and the
client were fairly indipendent.
Question 3-c
The sequence number used in the first byte of the application data sent from the
TCP client to the TCP server is within the [ACK] packet sent from the client.
The sequence number is d6,c1,a4,47.
Question 3-d
The window sizes exchanged between the client and server were 5856 from the
server and 5792 from the client. They agreed on the smaller one--5792.
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
19 60.121971 10.0.5.22 10.0.5.11 TCP
Info
23 > 36862 [FIN, ACK] Seq=135 Ack=160 Win=5792 Len=0 TSV=5933327 TSER=5873244
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
20 60.122243 10.0.5.11 10.0.5.22 TCP
Info
36862 > 23 [FIN, ACK] Seq=160 Ack=136 Win=5856 Len=0 TSV=5933135 TSER=5933327
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
21 60.122395 10.0.5.22 10.0.5.11 TCP
Info
23 > 36862 [ACK] Seq=136 Ack=161 Win=5792 Len=0 TSV=5933328 TSER=5933135
--------------------------------------------------------------------------------
Question 3-e
We observed that the TCP client and the TCP server both had the same MSS value.
That was 1460 bytes.
Question 3-f
The time of establishing the TCP connection was calculated as the time interval
of the [SYN] packet from the client to the server and the [ACK] packet from the
client to the server. The connection was built during the three way handshake.
60.122395 - 60.121971 = 0.000424 sec
We then terminated the telnet from the client end by typing a `quit` command.
Question 4-a
The packets that were involved in closing the TCP connection were [FIN],
[FIN, ACK], and [ACK] packets. The client, PC2, sent out a [FIN] packet to the
server requesting a termination of the connection. The server, PC1, sent out a
[FIN, ACK] packet to ack this request. The client further sent a [ACK] as a
response, and then the connection was terminated.
Question 5-a
We did another experiment by waiting for the server to terminate the conncetion.
We observed a 60 sec time out. After the time out, the server sent out a [FIN]
packet to request the conncetion termination. The client sent back [FIN, ACK]
packet and the server responed by another [ACK] packet. Then the connection was
terminated.
Question 5-c
It took the telnet server 60 sec until it closed the TCP connection.
[Exercise 4B]
We started a new wireshark traffic capturing on PC1 interface 1 with no filter.
We set a static entry in the ARP table on PC1 for an unexsiting IP address using
command `arp -s 10.0.5.100 00:01:02:03:04:05`. We used `arp -nr` to check the
entry. We tried to establish a telnet connection to this IP address using
command `telnet 10.0.5.100`.
Question 3-a
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
1 0.000000 10.0.5.11 10.0.5.100 TCP
Info
40430 > 23 [SYN] Seq=0
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
2 2.000000 10.0.5.11 10.0.5.100 TCP
Info
40430 > 23 [SYN] Seq=0
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
3 8.000000 10.0.5.11 10.0.5.100 TCP
Info
40430 > 23 [SYN] Seq=0
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
4 20.000000 10.0.5.11 10.0.5.100 TCP
Info
40430 > 23 [SYN] Seq=0
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
5 44.000000 10.0.5.11 10.0.5.100 TCP
Info
40430 > 23 [SYN] Seq=0
--------------------------------------------------------------------------------
No. Time Source Destination Protocol
6 92.000000 10.0.5.11 10.0.5.100 TCP
Info
40430 > 23 [SYN] Seq=0
--------------------------------------------------------------------------------
The time intervals of the packets were: 3, 6, 12, 24, and 48. This mechanism is
know as binary exponential backoff.
Question 3-b
After 6 [SYN] packets the TCP client gave up and reset the connection by sending
a [RST] packet.
Question 3-c
We set up a static ARP entry for an unexisting IP address in order to observe
the scenaria when the conncetion could not be built.
[Exercise 4C]
We started a new wireshark traffic capturing on PC1 interface 1 with no filter.
We tried to establish the telent connection on port 80, which does not have a
TCP server running. We used command `telnet 10.0.5.22 80`.
Question 2-a
The remote host closed the connection by resetting it. We calculated the time
it took to end the concetion. That was the time interval from the last [SYN]
packet to the [RST, ACK] packet.
0.000274 - 0.000091 = 0.000183 sec
