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