This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Ethernet packet & ARP

0

From viewing a random capture taken on a Windows host in my network, is it normal to see two different structured ARP related packets:

  1. An ethernet frame with a broadcast destination address of FF:FF containing an ARP request with a target hardware address of 00:00
  2. An ethernet frame where the hardware destination address AND target hardware address are the same

Are there any specific scenarios that would explain where you would see the packet structured in point 1 over point 2 & vice versa?

asked 27 Aug '15, 06:11

Brad_101's gravatar image

Brad_101
415811
accept rate: 0%

edited 27 Aug '15, 06:13


One Answer:

3

UpdatedAnswer because a trace was posted:
In the tracefile different forms of ARPs could be seen:
Case 1: Frame #1, A normal Broadcasted ARP-Request
Case 2: Frame #2, It is a normal Unicast Response to a ARP Request
Case 3: Frame #11, An Unicast ARP request mostly used to refresh the ARP Cache
Case 4: Frame #6, It is marked as Gratious ARP (Reply) by Wireshark, but in accordance to the RFC 3927 it is an ARP Announcement)
Case 5: Frame #17, It is marked as Gratious ARP (Reply) and also as a duplicated IP by Wireshark, but in accordance to the RFC 3927 it is an ARP Announcement)

So the problem is that the IP address 192.168.0.120 is used by 3 MAC addresses. Of course it could be, that these MAC Adresses belongs to the same host. But nevertheless if I were you, I would investigate it if it is correctly.

Here is a nice link about ARP: http://linux-ip.net/html/ether-arp.html


Next I have listed some special types of ARP packets:

The Gratious ARP Request:
A gratuitous ARP request is an ARP request packet, in which the source and destination IP are both set to the IP of the machine, which is issuing the packet and the destination MAC is the ff:ff:ff:ff:ff:ff broadcast address. Ordinarily, the reply packet will not occur.
Example:

Frame 1: 42 bytes on wire (336 bits), 42 bytes captured (336 bits)
Ethernet II, Src: 00:b0:9f:38:a3:d5, Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request/gratuitous ARP)
    Hardware type: Ethernet (1)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (1)
    [Is gratuitous: True]
    Sender MAC address: 00:b0:9f:38:a3:d5
    Sender IP address: 192.168.10.2 (192.168.10.2)
    Target MAC address: Broadcast (ff:ff:ff:ff:ff:ff)
    Target IP address: 192.168.10.2 (192.168.10.2)
 

The Gratious ARP Response/Reply
A gratuitous ARP reply is an ARP Response/Reply packet, in which the source and destination IP are both set to the IP of the machine, which is issuing the packet and the target MAC is the sender MAC. A gratuitous ARP Response/Reply is a reply, to which no request has been made. It could be a in some cases a directed one. (For example duplicate Address detection)
Example:

Frame 1: 42 bytes on wire (336 bits), 42 bytes captured (336 bits)
Ethernet II, Src: 00:b0:9f:38:a3:d5, Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (reply/gratuitous ARP)
    Hardware type: Ethernet (1)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: reply (2)
    [Is gratuitous: True]
    Sender MAC address: 00:b0:9f:38:a3:d5
    Sender IP address: 192.168.10.2 (192.168.10.2)
    Target MAC address: 00:b0:9f:38:a3:d5
    Target IP address: 192.168.10.2 (192.168.10.2)

The ARP Probe RFC 3927
A host probes to see if an address is already in use by broadcasting an ARP Request for the desired address. The client MUST fill in the 'sender hardware address' field of the ARP Request with the hardware address of the interface through which it is sending the packet. The 'sender IP address' field MUST be set to all zeroes, to avoid polluting ARP caches in other hosts on the same link in the case where the address turns out to be already in use by another host.
In addition, if A host MUST respond to a conflicting ARP packet as described in either (a) or (b) below:

(a) Upon receiving a conflicting ARP packet, a host MAY elect to immediately configure a new IPv4 Link-Local address as described above, or (b) If a host currently has active TCP connections or other reasons to prefer to keep the same IPv4 address, and it has not seen any other conflicting ARP packets within the last DEFEND_INTERVAL seconds, then it MAY elect to attempt to defend its address by recording the time that the conflicting ARP packet was received, and then broadcasting one single ARP announcement, giving its own IP and hardware addresses as the sender addresses of the ARP. Having done this, the host can then continue to use the address normally without any further special action. However, if this is not the first
Example

Frame 1: 42 bytes on wire (336 bits), 42 bytes captured (336 bits)
Ethernet II, Src: 00:b0:9f:38:a3:d5, Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol 
    Hardware type: Ethernet (1)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: reply (2)
    [Is gratuitous: True]
    Sender MAC address: 00:b0:9f:38:a3:d5
    Sender IP address: 0.0.0.0
    Target MAC address: 00:00:00:00:00:00
    Target IP address: 192.168.10.2

The ARP Announcement RFC 3927
An ARP announcement is identical to the ARP Probe described above, except that now the sender and target IP addresses are both set to the host's newly selected IPv4 address. The purpose of these ARP announcements is to make sure that other hosts on the link do not have stale ARP cache entries left over from some other host that may previously have been using the same address.
In addition, if during this period the host receives any ARP Probe where the packet's 'target IP address' is the address being probed for, and the packet's 'sender hardware address' is not the hardware address of the interface the host is attempting to configure, then the host MUST similarly treat this as an address conflict and select a new address as above.This can occur if two (or more) hosts attempt to configure the same IPv4 Link-Local address at the same time.
Example

Frame 1: 42 bytes on wire (336 bits), 42 bytes captured (336 bits)
Ethernet II, Src: 00:b0:9f:38:a3:d5, Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol 
    Hardware type: Ethernet (1)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: reply (2)
    [Is gratuitous: True]
    Sender MAC address: 00:b0:9f:38:a3:d5
    Sender IP address: 192.168.10.2
    Target MAC address: 00:00:00:00:00:00
    Target IP address: 192.168.10.2

answered 27 Aug '15, 07:46

Christian_R's gravatar image

Christian_R
1.8k2625
accept rate: 16%

edited 27 Aug '15, 14:58

Thanks Christian.

What would a frame look like containing a 'normal' ARP request? I thought the first case above would have been it(?).

After posting the question, I noticed that in the second case it is in fact an ARP request to a VRRP IP but the ARP header doesn't mention 'gratuitous'. Would you still feel that frame is a gratuitous ARP request?

I am just trying to understand what would be normal, what they'd look & in what conditions/scenarios you'd expect to see other (perhaps gratuitous) ARP's and what would they look like - how would you differentiate one from the other basically....

(27 Aug '15, 08:33) Brad_101

Yes you are right, I mixed the fields. It would be easier to talk about with a picture.
Case 1: is a normal ARP Request.

(27 Aug '15, 11:47) Christian_R

Please upload a capture file somewhere publicly accessible, like www.cloudshark.org, and post a link to the capture file.

You said "An ethernet frame where the hardware destination address AND target hardware address are the same." A gratuitous ARP is when the sender IP address and target IP address are the same, not when the hardware addresses are the same.

To give a meaningful answer, we need to see the actual Ethernet frames, including hardware addresses, IP addresses, and opcode field.

If the Ethernet destination address and the target hardware address are the same, that simply means that it is a unicast ARP, which can be seen in different circumstances.

(27 Aug '15, 12:10) Jim Aragon

@Jim Aragon: Yes you are right with the tracefile. I read some of the question details wrong.

(27 Aug '15, 12:16) Christian_R

https://drive.google.com/file/d/0BxWWq7ozi-PFakpYbEJfYzBQMFU/view?usp=sharing

With this example capture:

  1. Is packet 1 & 2 a normal ARP request and reply?
  2. What is packet 27 & 28 then? The destination IP is a VRRP IP (hosts default gateway). The ethernet destination address is the MAC address of the target IP address which the ARP request is asking for - why is that?
(27 Aug '15, 13:15) Brad_101

I am preparing an answer... it will be a longer one

(27 Aug '15, 13:38) Christian_R

Fram27 is Case 3. Frame28 is Case 2.

The VRRP device is only allowed ro communicate with his VRRP addres. And sometimes every Device refreshes his ARP cache. To reduce Broadcasts they try ot fitst as an Unicast ARP Request.

(27 Aug '15, 21:44) Christian_R

Thanks Christian for your help.

(28 Aug '15, 06:34) Brad_101
showing 5 of 8 show 3 more comments