Wireshark-users: Re: [Wireshark-users] Wireshark-users Digest, Vol 36, Issue 33
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: "noah davids" <ndav1@xxxxxxx>
Date: Wed, 20 May 2009 19:11:46 -0700
Thank you Martin,
I agree that some of the ARPs happen at 5 min intervals - which is the ARP cache timeout, but why are the rest occurring and why are there gaps, instead of at every 5 minute interval (I know that pings are sent every 5 minutes so that it is not an issue of no arp is necessary because there is no traffic).
Yes 10.20.1.1 is the default gateway. And no the route is not connected to 10.26.1.0/24. I agree I would not expect it to send a reply. But then again using arping I have sent ARPs using IP addresses from bogus networks and gotten replies from other devices. It appears that they just swap the IP addresses in the ARP packet, add in their own MAC address, and send the reply back to the Ethernet address without caring that technically the IP address is unreachable. Of course this device has every right to behave differently. Unfortunately I cannot test 10.20.1.1 that way.
There are 4 NICs, two are bonded to crate 10.20.1.39 and two are bonded to create 10.26.1.39. The individual NICs do not have an IP address. No clustering software. 

Good idea unfortunately it is 00 12 83 01 02 03 which I believe is unicast



Noah Davids
=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Serendipity is a function of bandwidth
----- Original Message ----- 
Message: 3
Date: Tue, 19 May 2009 10:46:11 +1000
From: Martin Visser <martinvisser99@xxxxxxxxx>
Subject: Re: [Wireshark-users] Strange ARPs
To: Community support list for Wireshark
<wireshark-users@xxxxxxxxxxxxx>
Message-ID:
<b3739b0c0905181746s44445da3m6220583e2e59c368@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

A couple of things
1. Some of the ARP intervals seem to be at regular spacings of 5 minute and 
1 minute, so not so random
2. I presume 10.20.1.1 is your default gateway. When you say you don't get
responses for ARPs from 10.26.1.39, you need to determine whether that
router has a sane IP network.route knowledge. If it doesn't believe that
10.26.1.39 is directly reachable from the interface it receives it I expect 
it won't respond.
3. If your multiple NICs are configured as a bond/team/bridge then that
could be a reason that ARP requests from 10.26.1.39 could be sent by the
10.20.1.39 interface. If you have some form of clustering software installed 
it might trigger such behaviour. Sometimes they can use gratuitous ARP
http://wiki.wireshark.org/Gratuitous_ARP
4. Just check that NortelNe_01:02:03 is infact unicast (disable MAC name
resolution). Some vendors register both unicast and multicast OUIs. The
first byte will be even if unicast, odd if multicast.
5. Often other traffic can trigger the ARP. If another protocol has learned about a potential host (through say a DNS response) then this will help you 
understand why the ARP has occured. ARPs are issued to either learn about
what physical address is need to send the next packet, or claim your own MAC 
address on the wire.

Regards, Martin

MartinVisser99@xxxxxxxxx


On Mon, May 18, 2009 at 12:39 PM, noah davids <ndav1@xxxxxxx> wrote:


This is really a question concerning the behavior of ARP and not a
wireshark
question. I apologize to everyone for the misuse of the list but figured
that the readers of this list would be my best bet for getting an answer.

I have a trace captured by tcpdump on a specific interface (but displayed
with wireshark) that shows two behaviors I do not understand.
First there are unicast ARPs to a specific IP address. The destination MAC 
address of the ARP requests is that of the ARP's target host. These ARPs
appear to be sent at random times. Second, the system will sometimes switch 
to using the source IP address of a different interface on the system, an
interface that is on a different subnet.

I have found some information indicating that unicast pings can be some
form
of test packet. But the random times leads me to believe that that is not
the case here I I would think that a test packet would be very regular).
Also I am totally stumped as to why the source IP address would change. The 
system is a Red Hat 2.6 Linux kernel

A complete display of the trace and my questions can be found here
http://members.cox.net/ndav1/traces/strange_arps.html but here a couple of 
sample packets

 142993 19:30:20.005254   Nec_ab:cd:ef    NortelNe_01:02:03     ARP
 Who
has 10.20.1.1?  Tell 10.20.1.39
 144132 19:35:19.305579   Nec_ab:cd:ef    NortelNe_01:02:03     ARP
 Who
has 10.20.1.1?  Tell 10.20.1.39
 145323 19:40:19.286200   Nec_ab:cd:ef    NortelNe_01:02:03     ARP
 Who
has 10.20.1.1?  Tell 10.20.1.39
 145643 19:41:44.964578   Nec_ab:cd:ef    Broadcast                   ARP
Who has 10.20.1.1?  Tell 10.26.1.39
 145654 19:41:45.996555   Nec_ab:cd:ef    Broadcast                   ARP
Who has 10.20.1.1?  Tell 10.26.1.39
Note that 10.20.1.1's MAC address is NortelNe_01:02:03 and it does respond to the unicast ARPs but not to the broadcast ARPs coming from 10.26.1.39.. 


Noah Davids
=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Serendipity is a function of bandwidth