1. DHCP messages are sent over UDP.
3. 58:6d:8f:0f:dd:9f
4. The identification value seems to be the only thing that differentiates the messages.
5. The transaction ID value of the first set is: 0x868096c4
The transaction ID value of the second set is: 0x44575b0c
The purpose of the transaction ID seems to be a way for the messages to stay grouped together.
6. The value used until an IP address is assigned appears to be 0.0.0.0.
Discover: Source: 0.0.0.0 Destination: 255.255.255.255
Offer: Source: 10.33.37.126 Destination: 10.33.37.45
Request: Source: 0.0.0.0 Destination: 255.255.255.255
ACK: Source: 10.33.37.126 Destination: 10.33.37.45
7. 10.40.4.45
8. 10.33.37.45. The DHCP offer message contains it.
9. The fact that the relay agent's address in the screenshot is 0.0.0.0 indicates that there isn't one. My experiment does contain a relay agent. The address of it is: 10.33.37.126.
10. The subnet mask and router lines in the frame are necessary to correctly route the data to my computer.
11. The same thing happens. The IP address is requested.
12. The "lease time" refers to how long you can use that particular IP address. The lease time on my current IP address is one day.
13. The release packet signifies that the host wants to stop using that particular IP address. There is no acknowledgement for a release packet. If the packet wasn't received, you would just continue using your existing IP address.
14. There was a large amount of ARP packets present.
Tuesday, April 24, 2012
Wireshark Lab 6: Ethernet and ARP
(Like the last few assignments, I've completed this one using the capture file provided by the book's authors)
1. 00:d0:59:a9:3d:68
2. 00:06:25:da:af:73.
3-5. I can't seem to find the information required to answer these questions.
6. 00:06:25:da:af:73.
7. 00:d0:59:a9:3d:68. I can't tell if it's my computer's ethernet address as I'm using the premade capture file.
8-10. Like above; I cannot seem to find the info required to answer these questions.
11. Screenshot of ARP cache: http://img801.imageshack.us/img801/1988/arpcache.png
12. Source: 00:d0:59:a9:3d:68 Destination: ff:ff:ff:ff:ff:ff
14.
c. Yes, the IP address is present in the ARP message.
16: Source: 00:06:25:da:af:73 Destination: 00:d0:59:a9:3d:68
1. 00:d0:59:a9:3d:68
2. 00:06:25:da:af:73.
3-5. I can't seem to find the information required to answer these questions.
6. 00:06:25:da:af:73.
7. 00:d0:59:a9:3d:68. I can't tell if it's my computer's ethernet address as I'm using the premade capture file.
8-10. Like above; I cannot seem to find the info required to answer these questions.
11. Screenshot of ARP cache: http://img801.imageshack.us/img801/1988/arpcache.png
12. Source: 00:d0:59:a9:3d:68 Destination: ff:ff:ff:ff:ff:ff
14.
c. Yes, the IP address is present in the ARP message.
16: Source: 00:06:25:da:af:73 Destination: 00:d0:59:a9:3d:68
Monday, April 23, 2012
Wireshark Lab 5: ICMP
(The ping command doesn't seem to be working. Every site I try to ping just returns "Request Timed Out". Here's a screenshot of a ping on Google timing out:
http://img706.imageshack.us/img706/7663/googletimeout.png )
1. Host IP: 149.152.37.45
Destination IP: 143.89.14.34
2. IMCP is a session-less protocol, therefore it doesn't use ports.
3. The ping request packet has "type: 8" and "code: 0". The other fields are: checksum(be), checksum(le), sequence number(le) and sequence number(be).
4. I can't answer this question since I wasn't able to get a response from any of the hosts I pinged.
(These questions were answered with the capture file provided by the book's authors.)
5. Host IP: 192.168.1.101
Destination IP: 138.96.146.2
6. Yes, it would.
7. No. They're the same.
8. The extra fields in the error packets seem to be extra copies of the IPv4 header.
9. They contain less information, and have different Time To Live values and identification values. They're different because the ICMP packets were actually received, and didn't get an error.
10. I can't answer this question, as tracert also causes a time out when I try to use it, like ping.
http://img706.imageshack.us/img706/7663/googletimeout.png )
1. Host IP: 149.152.37.45
Destination IP: 143.89.14.34
2. IMCP is a session-less protocol, therefore it doesn't use ports.
3. The ping request packet has "type: 8" and "code: 0". The other fields are: checksum(be), checksum(le), sequence number(le) and sequence number(be).
4. I can't answer this question since I wasn't able to get a response from any of the hosts I pinged.
(These questions were answered with the capture file provided by the book's authors.)
5. Host IP: 192.168.1.101
Destination IP: 138.96.146.2
6. Yes, it would.
7. No. They're the same.
8. The extra fields in the error packets seem to be extra copies of the IPv4 header.
9. They contain less information, and have different Time To Live values and identification values. They're different because the ICMP packets were actually received, and didn't get an error.
10. I can't answer this question, as tracert also causes a time out when I try to use it, like ping.
Wireshark Lab 4: IP
(NOTE: I'm using the capture file provided by the book's authors because the traceroute program wasn't working as it should)
1. 192.168.1.102
2. ICMP (1)
3. There are 20 bytes in the IP header. There should be 36 bytes in the payload, since the packet size was 56 bytes and the header size is 20 bytes.
4. They do appear to be fragmented, as there are many IPv4 packet fragments in the capture window.
5. The TTL (Time To Live) is different in each one. The identification field also changes.
6. The host, destination, header size and fragment offset fields all stay the same.
7. The identification field changes by one for each new packet.
8. The TTL is 254, and the identification field is 0.
9. Yes, the values stay constant for all the TTL exceeded replies from that particular router.
10. Yes, it has been fragmented across more than one IP datagram.
11. I know this packet is fragmented because there is a field that says "Reassembled IPv4 in frame 100", which implies that it is a fragment. This datagram fragment is 1480 bytes.
12. There doesn't seem to be anything in the header that indicates that it is not the first fragment. There are more fragments, I can tell by looking in the capture window.
13. Identification and Time To Live are the fields that get changed between fragments.
14. Two fragments were created from the original datagram.
15. The Time To Live, header checksum and fragment offset fields all change between the fragments.
1. 192.168.1.102
2. ICMP (1)
3. There are 20 bytes in the IP header. There should be 36 bytes in the payload, since the packet size was 56 bytes and the header size is 20 bytes.
4. They do appear to be fragmented, as there are many IPv4 packet fragments in the capture window.
5. The TTL (Time To Live) is different in each one. The identification field also changes.
6. The host, destination, header size and fragment offset fields all stay the same.
7. The identification field changes by one for each new packet.
8. The TTL is 254, and the identification field is 0.
9. Yes, the values stay constant for all the TTL exceeded replies from that particular router.
10. Yes, it has been fragmented across more than one IP datagram.
11. I know this packet is fragmented because there is a field that says "Reassembled IPv4 in frame 100", which implies that it is a fragment. This datagram fragment is 1480 bytes.
12. There doesn't seem to be anything in the header that indicates that it is not the first fragment. There are more fragments, I can tell by looking in the capture window.
13. Identification and Time To Live are the fields that get changed between fragments.
14. Two fragments were created from the original datagram.
15. The Time To Live, header checksum and fragment offset fields all change between the fragments.
Subscribe to:
Posts (Atom)