[ale] Slightly OT: Decyphering 'arp' error
timothy at meanor.net
Wed Oct 22 10:59:53 EDT 2008
You know the offending device's IP address, so try running nmap
against it (with your device shutdown, of course), or if you don't
have nmap available, just try telneting to various ports to see what's
running. You can also get the MAC address of the device via arp. The
first three bytes are specific to the vendor of the NIC, so you can
use http://standards.ieee.org/regauth/oui/oui.txt to figure out the
make of the NIC. Might give you a clue as to what the device is (e.g.
if the first 3 bytes of the MAC are 00-01-C7, it's a Cisco device of
On Wed, Oct 22, 2008 at 10:03 AM, John Mills <johnmills at speakeasy.net> 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
> NOTE: The network device is an embedded product based on eCos, using an
> older BSD network stack. The DHCP server is (I believe) Microsoft.
> TIA for any pointers.
> - Mills
> Ale mailing list
> Ale at ale.org
More information about the Ale