In this demonstration,
we will cover capturing ARP using Wireshark Network Protocol Analyzer version 2.
4.
3.
I will cover the same ARP request and reply communication process you
learned in the presentation using live systems.
By the end,
you will understand the address resolution protocol
header and the information it contains.
To get started, I'm going to open an administrator level command prompt.
First, I want to check my IP address and my MAC address with an ipconfig/all.
Here, you can see my MAC address has 00-0C-29-F2-AC-34.
My IP address is set to 20.
1.
4 with my default-gateway set to 20.
1.
I also want to check the current entries within my ARP cache.
There are two dynamic entries.
The first is my default-gateway with the IP address with 20.
1.
1 and MAC address 00-23-5e-e2-5f-ee.
The second is the IP address of another system in my LAN 20.
1.
9 and it's associated MAC address.
Please remember that whenever my system needs to send
data to a destination IP address,
an associated destination MAC address must also be
added to the data before sending.
My systems process is to check the ARP cache for a
matching IP and add the associated MAC.
If data is destined for another network,
then the default-gateway's MAC address will be used.
If there is no matching entry,
ARP requests and ARP reply packets are used to query the network.
This means I can generate ARP traffic simply by sending data
to systems not present in my ARP cache.
To start my capture,
I'm going to start Wireshark and start my capture on my Ethernet0 interface.
I'm going to return to my command prompt and I'm going to
ping something not within my ARP cache, 20.
1.
8, for example.
I'll also ping 20.
1.
7.
To view this ARP traffic, I'll return to my Wireshark.
To view my ARP traffic more easily,
I'm going to add a display filter in the display filter line.
I'll type arp, this will filter by ARP traffic alone.
We're going to start by taking a look at our first ARP packet number 13.
Check out the source and destination columns.
The source is a particular MAC address while the destination says Broadcast.
The Protocol column naturally says ARP and the Info column says Who has 20.
1.
8 Tell 20.
1.
4.
Let's look at the packet details to explore this further.
Within the Ethernet header again, we have the source MAC address,
which again, is the MAC address of my own network card.
The destination is a Broadcast all Fs.
As a broadcast, ARP requests will be sent to all stations on the LAN,
however,
it is important to note that your default-gateway
router will receive this packet,
but not forward it as routers don't forward broadcasts by default.
Notice that in the ethernet header,
there is a type field that tells us that the ARP
protocol is contained in this frame.
Now let's look in the Address Resolution Protocol header.
We start with a field called Hardware type.
Currently, that's set to 1 for our ethernet network.
The second field, Protocol type, is set to hexadecimal 0800,
which stands for IPv4.
Our third and fourth fields, Hardware size and Protocol size,
are set to the size of our MAC address 6 bytes and
the size of our IP address 4 bytes.
The next field, Opcode, is set to 1,
which lets systems know that this is an ARP request.
Following the Opcode is a Senders MAC and Senders IP address,
again, that's set to my systems MAC and IP as I'm doing the ARPing.
Notice that the target IP address is the one I added in my ping
and the target MAC address is set to all 0s.
Essentially,
this address resolution protocol request is asking
everyone on the network who has 20.
1.
8 or what is the MAC address of that system.
Now let's take a look at the ARP reply.
Just as I explained in the presentation,
an ARP reply is a unicast packet going from one
specific source to a specific destination.
If we look within the ethernet header,
the source is the Inventec network card with the MAC
address 00:8c:fa:67:19:20 and the destination is the VMware
network card at 00:0c:29:f2:ac:34.
Again, the type field says that an ARP packet is contained.
A bit of difference here though is the padding.
The ARP reply is so small it doesn't even meet the ethernet
minimum specifications for frame size, and so padding has to be added.
If we look within the address resolution protocol header,
we see that it says reply and that's specifically
because the Opcode is now set to 2.
Our first four fields, however, remain the same.
Hardware type is still ethernet, protocol type is still IPv4,
hardware size, our MAC address is still 6 bytes,
and our protocol size, our IP address is still 4 bytes.
The change in the reply really comes in the last four fields.
First notice that the target IP address and MAC
address are the original requestor, my system which is trying to send the ping.
Then notice the senders MAC address and IP address are filled in with
the information to be populated in my ARP cache.
The sender is 20.
1.
8 with a MAC address 00:8c:fa:67:19:20.
Again,
that's what I'm going to be putting in my ARP cache and utilizing to send my ping.