Sie sind auf Seite 1von 21

NGUYEN THANH DUC 227316 Computer Networking Wireshark 1 & 2 Report Wireshark First Assignment:

Task 1: ICMP and traceroute


Using Wireshark on Window 7 platform, to capture ICMP message from localhost to website www.yahoo.fi NIC: JMiron PCI Express Gigabit Ethernet MAC address: 48.5B.39.60.46.19 IP address: 94.237.93.152 Subnet 255.255.252.0 Using command: Tracert www.yahoo.com 1. The picture show route table:

2. Attach the output file here:

3.

IP header have at least 20 bytes and maximum of 60bytes. Among the captured IP packets sent from localhost, these following fields change on IP header: - Version does not change, because all packets are IP version 4. 4 will be written to this field. - IHL (Internet header length) this field is not changed because all packets have 20-byte IP header. - Type of service: This field shows what type of service like throughput, priority, delays, reliability and it is not changed in this case. -Total length: This field indicates the total number of bytes of the IP packet. In this case, all of packets sent by localhost have the same total length 92-byte length packet. Its hexadeximal number is 5C. -Identification: This field indicates the unique number of the separate packets. This field is used for destination to join the separate packets. Therefore this field is changed for each different packet. -Flags and fragment offset are also not changed. Because the packets are not fragmented. -Time to live field is changed for different packets. -Protocol field is the same. Because all packets are ICMP protocol so it has 1 in this field. -Header checksum is of course changed for each packet. -Source IP address field is not changed and it shows IP address of localhost. -Destination field is the same.

4. As I said in the previous explanation, Identification field indicates the sequence number of sent IP packet by localhost computer. And the value of this field will be increased each time one packet sent by localhost. 5. In term of ICMP header of the packets sent by localhost computer: Type field, Code field Identifier field are not changed. The only change is Sequence number and then therefore checksum is also changed.

6. 64-byte data is sent for each Echo ping request packet. 7. The way how to indicate the date field of ICMP packet by Wireshark: Choose the Echo ping request packets sent by localhost computer on the Packet List panel. On Packet Detail window, we open the tree list and observing the number of data bytes by looking at data field. From below picture, we can easily realize the data field of the Echo ping request packet is 64-byte. And these data bytes are 00 by looking at Packet Byte when we highlight Data field on packet Detail window.

8. When observing the TTL exceeded packets in the capture, compared with Echo ping request, these kind of packets have more fields than those because TTL exceeded packet are actually the reply packets of previous Echo packets, so these have encapsulate all information of Echo packet and its IP header itself. That means IP header field will be encapsulated together with previous Echo request packet.

Task 2: TCP and File Transfer


1. To see the captured TCP data flow in the way that the Application layer sees it, select a TCP packet in the Packet List pane and then choose the Follow TCP Streammenu item from the pop-up.

2. TCP packet options field has 8 bytes and it shows 3 kind of information: Maximum segment size: 1460 bytes No-Operation (NOP) TCP SACK permitted Option: True 3. Maximum Segment Size (MSS) is the maximum amount of data can be separate into a sent packet over a transmission protocol. Maximum Segment Size use by localhost computer and server is the same 1460 bytes. It is calculated by MTU - 40 bytes. 40 bytes here are the total number of bytes for IP and TCP headers. For example, For Communication over Ethernet: MTU = 1500 so MSS = 1500-40 = 1460 bytes.

4. The Initial Window is limitation amount of data by sender to control avoidance congestion when the sender transmits data over the network before receiving an ACK. For large number of Web server usually use an IW of 2 segments. For the connection between localhost and Web-server in this case, Web-server used Initial Window of 2 segments. Each segment has MSS of 1460 bytes, that means IW will have 2*1460 = 2920 bytes. By looking at the TCP graph below, we will see the maximum of segments transferred continuously before receiving ACK frame.

5. Explain from the graph: To avoid congestion, TCP use congestion avoidance algorithm which is divided into different transmission phases:

The first phase of transmission, TCP uses slow start algorithm. That is why we see at first the sequence is transmitted with just a small amount. Then TCP increase remarkable the sequence number after slow start phase.

6. Explore TCP header during data transfer: This picture shows TCP header fields.

And below picture shows the information of TCP header fields of a TCP packet captured: The first field is Source Port and Destination Port indicate which ports are the source and destination machine using to dealing with data. Sequence number field indicates the position of the first data byte of data field in this TCP packet. Acknowledgement field will indicate the next first position of data indicated by the next TCP packet which receiver is expected to receive. Header length indicates the number of header bytes and in this case 20bytes header. Some status TCP flats indicates which phase of TCP connection is happening. Checksum field use to check error control.

Acknowledge flat is always set to 1. During connection establishment phase, SYN flat is set 1 and ACK flat is set 0. After connection is approval, SYN flat is down 0, and ACK is always set 1 which indicates that when data transfer is not terminated yet, and the sender is expecting the next sequence number of byte to receive which is stated in Acknowledgment Number field of TCP header. ACK flat

Task3. TCP AND INTERNET LIVE RADIO


1.

Explain: At the beginning of transmission, TCP transmit very fast. It reach the sequence number 75000 just only 1s. And then from that, transmission increase gradually. 2. The Graph shows the relation between Sequence number and time, this one has lots of differences compared with the graph obtained from previous task. The task2 picture has two data rates divided by two segment of time. The first amount of time from 0s to 1s, the data rate is slow or small because this time is the slow start algorithm phase. And then from 1s to 1.4s, the data rate is significantly increasing.

Conversely, in the second picture, the data rate is going on the opposite direction. The first division, it has very high data rate because from sequence 0 to sequence number of 50.000, it just spends 1s. And then data rate is reducing remarkable at the same level to 55s. 3. The size of the packets sent by radio station are different length, they are not fixed length. 4. Observing from the Time-Sequence Graph, I see that the playback phase begin from the approximate position of 1.5s corresponding to the sequence number of 70.000 approximately. Until the sequence number of 200000 has corresponding of the time 34s. Based on this information, I calculate the data rate of 30kbps. Compared with the given data rate selected at the Internet radio player on the web page (32kbit/s), I see that the calculated value 30kbps and 32kbps are nearly the same. The difference here I think due to some small errors of resolution of Graph by looking at some figures by my eyes.

Wireshark 2

Task1. Computing and Internet Checksum

Frame 2: IP Header Checksum Computation

Frame 2: IP Header Integrity Verification

IP Header

4500 + 0048

= 4548

= A204

5CBC + = 5CBC 0000 8011 + 6F8C = EF9D 82E6 + 3405 = B6EB 82E6 348B + = B771

= 1A688 = A688 + 0001 = A689 = B771 = B771

= 1488D = 488D + 0001 = FFFF = 488E (correct)

Frame 2: UDP Datagram Checksum Computation 82E6+3405 Pseudo IP Header = B6EB = 16E5C => 6E5D = 0484 0035+040A =043F UDP Header 0034+0000 =0034 = BC05 = BC07 = 0002 = DA12 = F3D6 = 15F3E => 5F3F Bitwise 25ED NOT = = 12EE8 => 2EE9 = 72E1

82E6+348B =B771

0011+0034

=0045

3A51+8180 =BBD1 0001+0001 0000+0000 Data 0377+7777 0374+7574 0266+6900 0001+0001 =0002 =0000 =7AEE =78E8 =6B66

= 6B68 =0002 C00E 8BDB C00C+0001 =C00D 0001+0000 =0001 07AF+0004 =07B3 82E6+0142 =8428

Checksum is 25ED = AB29

= 14BE9 => 4BEA

Frame 2: UDP Datagram Integrity Verification. 82E6+3405 Pseudo IP Header = B6EB = 16E5C => 6E5D = 0484 0035+040A =043F UDP Header 0034+25ED =2621 3A51+8180 =BBD1 0001+0001 0000+0000 Data 0377+7777 0374+7574 0266+6900 0001+0001 =0002 =0000 =7AEE =78E8 =6B66 = 6B68 =0002 C00E 8BDB = 14BE9 => 4BEA = AB29 C00C+0001 =C00D 0001+0000 =0001 07AF+0004 =07B3 82E6+0142 =8428 => 5F3F = F3D6 = 15F3E = 0002 = FFFF (Correct) = E1F2 = E1F4 = 154D5 => 54D6 = 72E1

82E6+348B =B771

0011+0034

=0045

Task2: TCP ZERO-WINDOW PROBING


TCP zero-window Probing 1. The name of the downloaded file is wrar371.exe. 2. - The maximum window size of client is 65535. - The maximum window size of the web server is 6996. 3.

Explain the obtained picture: The transfer data have been occurred after the connection is established. The server sends data and the receiver receives the data until the packet number 1213 at 1.201527s. The transfer data is hang out because the Window size of the client is full or the clients buffer is full and it cannot receive data. The client will send the announcement to server with ZERO-WINDOW. Server will send TCP KEEP-ALIVE packet and wait for until receiver executes its received data. The data transfer continues at 3.895820s when the receiver sends its update window size. That is why we see from the picture, it has the interrupted time from 1.2s to 3.9s. 4. The packet number 1214 says that the connection is still alive but idle for amount of time and the server is waiting for the update window size from receiver.

Because this packet is ACK packet, if the connection is corrupted because of a crash, this packet will be RTS packet instead of ACK one. -This packet has 8 bytes data. These byte data are called garbage bytes and are sent from server with IP packet to announce the idle connection and keep-alive connection due to zero-window size. These bytes are zero-value. -No, it does not agree with TCP specification given by RFC 1122. Because TCP specification suggests that coming with KEEP-ALIVE packet, the data has only 1 byte data. 5. RTO is the waiting time of the server for the first KEEP-ALIVE segment is sent when the ZERO-WINDOW have detected. By deriving the 1213 packet, I see that the RTT time is 0.000035s. => RTO = 1.483208 1.201527 RTT = 0.281646s = 8047*RTT 6. To know whether the server increase internal exponentially, we check the time bet packet number 1215 and 1216: K*RTO = 2.007222 1.483288 RTT = 0.523899 = 2*RTO Similarly, the time distance between packet number 1218 and 1217: M*RTO = 3.015228 2.007295 RTT = 1.007898 = approximately 4*RTO Conclusion, the time interval increases exponentially.

Task 3: TCP WINDOW SCALE OPTION


TCP Window scale option. 1.

Explain the observed graph: After connection establishment is finished, the data is sent. The sequence numbers are increasing significant exponentially. In this case there is no interruption as happed in the previous situation. Because the window is scaled larger enough for 1200000 bytes sequence. 2. The difference between Time-Sequence Graph of this case and previous case is that in this case the speed is increased. By looking at this graph, it can be seen that the

transmission can reach sequence number 1200000 byte only after 0.75s. While in the previous situation, to reach the sequence number 1200000, the transmission need 4.5s if the zero-window is taken into account. If we do not put zero-window into consideration, and the transmission is going through smoothly from sequence number 0 to sequence number 1050000, it takes 1.3s. In comparation with the two graphs, we see that the second case is faster than the first one and there is no interruption when the sequence number reaches 1050000. 3. The window scaling factor and the maximum window size of the client: By increasing the window size, it is allowed to store the sequence numbers which are greater than 64KB. The scaling window size option allows to optimize maximum window size of 1GB.The original window size is no longer larger than 64KB. The scale factor is to inform the receiver to know that, the transmitters are going to do window scale and offer window scale for communication. Clients: Window scale factor: 16384 = 2^14. Maximum window size = 1073725440 = 1GB Servers: Window scale factor: 128 = 2^7. Maximum window size = 7040GB 4. No, it is not possible to define actual window size from segments other than SYN and SYN/ACK segments. If TCP connection wants to expand their window size, it is only sent through SYN and SYN/ACK connection during connection establishment.

Das könnte Ihnen auch gefallen