Homework 4
Homework 4
201900033
HOMEWORK IV
WIRESHARK EXP:
Source: http://www.networksorcery.com/enp/protocol/802/ethertypes.htm
4. The “G appears exactly after 54 bytes, each line has 16 bytes and the G is situated at the
4th line at the 7th position = 16*3+6=54bytes.
First, there are 14 bytes for the ethernet frame as show in the picture:
Additionally, there as 20 bytes for the IP header in addition to 20 bytes for the TCP
header before the start of the HTTP message. There are in total 52 Bytes before the start
of the HTTP GET message and the G is situated just after 2 bytes from the start of the
HTTP GET message content.
5. The Ethernet source address is the address of my router: 10:13:31:18:5c:bb and not the
address of the website.
7. Same as in 3, the hex value 0x0800 represent the protocol used with the data after the
decapsulation of the Ethernet Frame which is IPv4.
8. “O” appears 67 bytes from the start of the Ethernet frame (16*4+3). Again, there are 14
bytes of Ethernet frame, and then 20 bytes of IP header followed by 20 bytes of TCP
header before the HTTP data is encountered additionally to 15 bytes from the start of the
HTTP OK message.
Part2:
9. The Internet Address column contains the IP address of the device, the Physical Address column
contains the MAC address, and the type indicates the type of the ARP entry(protocol:
dynamic/static)
10. The source address of the ARP message (broadcast) is the router itself: e8:2a:44:dc:0c:5d
While the destination address is ff:ff:ff:ff:ff:ff (broadcasting to all device in the LAN)
11. The hex value of the two-byte Frame field is 0x0806 which correspond to the ARP upper
layer protocol.
12. a) The ARP opcode field begins 20 bytes just after the beginning of the Ethernet Frame.
b) The hexadecimal value for opcode field within the payload of an ARP request is
0x0001→request
c) Yes, the ARP message does contain the IP address 192.168.2.114 of the sender of the
request.
d) The field “Target MAC address” is set to 00:00:00:00:00:00 to ask the machine with
the corresponding IP address (192.168.2.181) to reply.
13. a) The ARP opcode field begins 20 bytes from the very beginning of the Ethernet frame.
b) The hexadecimal value for opcode field in the ARP payload for a request is 0x0002
→reply
c) The initial device that issued the request will receive a reply. The answer of the request
is contained in the ARP reply in the sender MAC: 60:36:dd:e7:83:7b address where the
IP correspond the sender of the reply: 192.168.2.181.
14. The hex value for the source address is 60:26:dd:e7:83:7b and for the destination is
e8:2a:44:dc:0c:5d in the ARP reply message.
15. In the following network, our device has sent a request message to know the MAC
address of the device that have IP=192.168.1.1 (first ARP message)
Our device receives the reply with the corresponding MAC address (second ARP
message)
But the third ARP message correspond to another device that sent a broadcast to know
the MAC address of the device with IP=192.168.1.117, but our device has a different
IP=192.168.1.105. Our device won’t send a reply because the IPs don’t match. The
device with the corresponding IP will be replying and not our device.
Extra Credit:
EX1-
The answer for this question is that once the adaptor or router received the destination IP
address (even with the wrong MAC address), the router/adapter would remove the IP address
from the Ethernet Frame and using ARP, he would get the correct MAC address of the
destination.
If I cleared my ARP table and added a false MAC address using arp -s, I wouldn’t be able to
ping the the corresponding Ip address from my PC. After clearing the entry or simply waiting
the time out of the cache entry, we would get the correct MAC address by a broadcast and we
would able to connect to the other entry.
EX2-
When an ARP entry is made, it has a maximum lifetime. If the entry is still reachable in
network, it will be stored for a maximum time of “Reachable Time”. If it is still reachable
after this time, the host will send an ARP request to recheck the entry.
If the entry is no longer reachable, the entry is retrieved from the table
https://support.microsoft.com/en-us/help/949589/description-of-address-resolution-protocol-arp-
caching-behavior-in-win