cn reportsadsds

7/29/2019 Cn Reportsadsds

1/27

Name: Amgad Tarek Abdelaty Mohamed

ID Number: 10110109

Course Number: EE-305

Topic: Computer:Network Project Using Wireshark

Date of Submission: 02-Jan-2013


2/27

Wireshark Lab: UDP

1. There are 4 fields as follows: source port, destination port, checksum and length.

2. 2 bytes.

3. It is the sum of header length and the data length since, each field in the header has a size of 2

bytes then, there are 8 bytes for the header and data got 46 bytes. So, in total we get 8 + 46 = 54


3/27

4. Due to the use of Ipv4 then maximum number of bytes that can be included in a UDP payload is

(2^16)-header length = 65536 8 - 1 = 65527. The practical limit for the data length which is

imposed by the underlying Ipv4 protocol is 65507 bytes which is (65535 8 -20 bytes the IP

header).5. (2^16) 1 = 65535

6. It is 17 in decimal and 0x11 in hexadecimal.

7. The method of calculating the checksum is defined in RFC 768: Checksum is the 16-bit one's

complement of the one's complement sum of a pseudo header of information from the IPheader, the UDP header, and the data, padded with zero octets at the end (if necessary) to make

a multiple of two octets. In other words, all 16-bit words are summed using one's complement

arithmetic. The sum is then one's complemented to yield the value of the UDP checksum field.If the checksum is computed to be 0, it must be set to 0xFFFF.
http://en.wikipedia.org/wiki/One's_complementhttp://en.wikipedia.org/wiki/One's_complementhttp://en.wikipedia.org/wiki/One's_complementhttp://en.wikipedia.org/wiki/One's_complement


4/27

8. The UDP sent packet

The UDP reply packet.

The source port of the first packet has 29935 as a source port and 24080 as a destination port and thereply packet got its source port 24080 and the destination port 29935. So, the source port of the sent

packet is the same as the destination port of the reply packet and the destination port of the sent packet

is the same as the source port of the reply packet.


5/27

Wireshark Lab: IP

1. 192.168.1.117


6/27

2. The value in the upper layer protocol field is (1) in decimal or 0x01 in hexa.

3. Th IP header got 20 bytes. Since, the total length of this ping message is 56 bytes then, thepayload length is 56 20 = 36 bytes.

4. No, it hasn't been fragmented. Since, the more fragment is not set.


7/27

5. Identification, Header checksum and time to live always change.

The first ICMP request packet

The second ICMP request packet


8/27

The highlighted fields are the ones that change.

6. The fields that stay the same and must be the same:

Header Length stays the same since all of these packets are ICMP.

Source IP stays the same since my computer is one always sending the pings.

Destination IP stays the same since I am always sending to the same destination.

Version stays the same since Ipv4 is being used for all the ICMP. Differentiated Services stays the same since all these packets are ICMP and use the same

type of service.

Upper Layer Protocol stays the same as the packets are ICMP.

The first ICMP packet

The second ICMP packet


9/27

The last two figures show the fields that stay the same.

The fields that must change are those mentioned in question 5.

Identification must change since each IP datagram must have its own identification.

Time to live must change since the tracerouter increments TTL each time it sends ICMP

request by 1. Header Checksum must change since, each time an ICMP is sent its header changes so

its header checksum must change too.

7. The identification field increases by 1 each time an ICMP ping is sent.

It shows the identification field and would be incremented in the next figure representing the next ping

The figure below shows the incremented ICMP ping


10/27

8. TTL = 64 & Identification = 9235 in decimal and 0x2413 in hexadecimal.

9. The identification field ICMP TTL-exceeded changes because it should be unique for each IP

datagram unless the datagram is a fragment of a larger datagram so, it would have the same idas the other fragments of the same large fragment. However, the TTL stays the same because

the first hop is always the same.

The figure below shows that the identification number has changed while the TTL stayed thesame.

10. Yes, it has been fragmented into more than 1 IP datagram, I got 2 fragments.


11/27

11. The more fragment field is set and contains 1. It is the first packet since, the fragment offset is

equal to 0 and it is 1500 bytes long the whole fragment.

12. Since the fragment offset is 1480 bytes and not 0 then we can say that it is not the first

fragment. It would be the last fragment since the more fragments field is not set.

13. The fields that change are the Fragment Offset, and Header Checksum and identification.

The first fragment.


12/27

The second fragment.

14. 3 fragments.

15. The fields change among the three packets are the fragment offset and the checksum. However,the fields that change between the first two fragments and the third one are the total length and

the flags. While the id changes in all of them.

The first fragment.

The second fragment.


13/27

The third fragment

Wireshark Lab: DHCP


14/27

1. UDP


15/27

2. DHCP discover and request have the same source port and the same destination port. Source

port is 68 and the destination port is 67. However, the DHCP offer and Ack have the samesource port which is 67 and the same destination port which is 68.

3. e8:39:df:4d:33:f5

4. The value in the option 53 is the one that differentiates between the discover message and the

request message.

Discover Message.


16/27

Request message.


17/27

5. Transaction ID of the first DHCP Discover is 0x6c3a48be. Transaction ID of the first DHCP

Offer is 0x6c3a48be. Transaction ID of the first DHCP Request is 0x6c3a48be. Transaction ID

of the first DHCP ACK is 0x6c3a48be.

Transaction ID of the second DHCP Request is 0x3d320b56. Transaction ID of the second DHCP ACK

is 0x3d320b56.

A Transaction ID is used so that the DHCP server can differentiate between client requests while

requesting.

6.

Type Source IP address Destination IP address

Discover 0.0.0.0 255.255.255.255

Offer 192.168.1.1 192.168.1.117

Request 0.0.0.0 255.255.255.255

ACK 192.168.1.1 192.168.1.117

7. 192.168.1.1

8. It gave me 192.168.1.117 and the Offer DHCP message contains the new IP address.


18/27

9. The relay agent IP address indicates whether a relay agent exists or not, when it 0.0.0.0 then

there is no relay agent. But, in my experiment there is a relay agent and its IP address is

192.168.1.1

10. The router helps the client to know its default gateway. The subnet mask tells the client about its

subnet mask.

11. In mine the host requests the offered IP address in the DHCP Request message.

12. The lease time is the time that the DHCP reserves a certain IP address to a certain client at that

time other clients can not have the same IP address unless the client release it or the lease time

passes, then the IP address is free to be assigned to any client. Mine is 1 day.


19/27

13. The client sends a release DHCP message to drop its IP address. There is no ACKs from the

server regarding the arrival of the release DHCP messages. If the release DHCP message is lost

then the server would have to wait till the lease time of this IP address given to that user is up

then it release it to be reused for other clients and assigns a new IP address to that client.

14. Yes there ARP packets sent. It is used by the server to make sure that the IP address it is going

to assign to some client is not being used by other clients.


20/27

Wireshark Lab: HTTP

Section 1:

1. 1.1


21/27

2. English-US and Arabic.

3. My IP address is 10.9.0.151 and the server's IP address is 128.119.245.12


22/27

4. 41 5.739653000 128.119.245.12 10.9.0.151 HTTP 482 HTTP/1.1 200 OK

(text/html)

5. wed, 02 Jan 2013 11:08:01 GMT


23/27

6. 128

7. All headers could be found in the raw data.

Section 2:

1. It is not there..


24/27

2. Yes it can be seen in the highlighted area in the figure below.

3. Yes, it checks if the page is updated or not.


25/27

4. Status code is 304 and the phrase returned Not Modified sine no updates occurred to the page.

Yes it did.

Section 3:

1. 2.

2. There are 5 data containing TCP segments containing 309 ,1452 ,1452, 1452and 144 bytes respectively for a total of 4500 bytes.

3. Status code = 200 and Response phrase is ok

4. No.


26/27

Section 4:

1. 128.119.245.12 , 128.119.240.90, 128.119.245.12 and 165.193.140.14 (4 addresses)

2. We this by checking how many TCP ports were used in the transmission. In our case 2 TCP

ports were used which means that it has been transmitted serially. So, it transfers the first imagefirst then the second.

Section 5:

1. status code is 401 and the response phrase is authentication required.

2. It is Authorization.


27/27

cn reportsadsds

Documents