[ale] Slightly OT: Decyphering 'arp' error

[Michael H. Warfield]

On Wed, 2008-10-22 at 10:03 -0400, John Mills wrote:
> ALErs -

> I have a network device that requests a DHCP address assignment on boot. 
> It expects and receives a particular address in our subnet. Shortly after, 
> it presents the following warning on the system log:

>   "arp: 0xc04ac1b4 is using my IP address 172.16.1.160!"


> That IP is supposedly reserved against my device's MAC, but apparently 
> there is a problem somewhere with the assignment. Presumably the 
> '0xc04ac1b4' identifies the hardware which has a conflicting claim to the 
> same IP. How can I use that data to help identify the conflicting unit? Is 
> there a test I can do to determine if the conflicting unit is responding 
> to net traffic? (I think of 'nmap' against the IP and looking for open 
> ports my application does not have, but that wouldn't work if the 
> conflicting device were similar to mine: it would then present the same 
> signature.)

	0xc04ac1b4 would be the MAC address of the offending device.

	00:00:c0:4a:c1:b4

	That would appear to be a Western Digital card, maybe an old one like
one of the ancient WD8003 cards.  I think they used that 00:00:C0 vendor
oid.

	Have you run a ping against that address with your network device off?
Do you get a host unreachable?  What do you get when you dump the arp
tables (arp -a) after that?  What's the MAC address of your device?

	Certainly run an nmap against that IP address.  Do that with your
device down.  If you find anything, try connecting to those ports and
look for banners.  If it's got 135 or 445 open, it's probably a Windows
machine, if it's got port 22 open, pretty good chance it's a *nix box of
some sort.

	If you don't find anything, it may be more of a challenge.  If it's
there on the wire and not responding to any services or pings but is
responding to arp's, you may need to chase it down wire by wire.  It may
be static configured or there may be an error in the dhcp configuration
that allowed it to give that address out (like maybe the address is
within the allocation pool and it was running low on addresses and
didn't recognize the static assignment for some reason).  If it's a dhcp
configuration problem, the offending node still might not give up the
address until the lease runs out or it tries to renew.

> NOTE: The network device is an embedded product based on eCos, using an 
> older BSD network stack. The DHCP server is (I believe) Microsoft.

	It sounds like it's offering the correct address to your device and
then your device doesn't like it when it tries to configure the address.
I'm inclined to believe that means someone put a static configured
device on the network.  I don't even think MS DHCP is that broken that
it would hand out an address to a machine when it has already allocated
it, static or otherwise.  ISC dhcpd will first ping and address and
abandon it in the logs for dynamic assignment and never offer it, but it
sounds like you do have a static assignment.

> TIA for any pointers.

>   - Mills
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20081022/c1d728b7/attachment-0001.bin