Home / server / Questions / 260333
Accepted
Stefan Lasiewski
Asked: 2011-04-16 20:01:03 +0800 CST

Network link layer equivalent of `ping` to probe a device which fell from the intranet?

  • 772

Here's my situation. It's hypothetical, but happens often enough to be a problem.

We have a generic layer 2 ethernet network switch. All of the devices connected to this switch use IP addresses in a 10.1.1.0/24 private network.

We attached a new device to this network, and it runs embedded Linux. We configured this device to use the 10.1.1.0/24 network. This device was working fine, but has mysteriously dropped off the network. We cannot connect to this device using traditional TCP/IP tools (ping, telnet 10.1.1.100 22, etc.).

We suspect that this device somehow got reset, and reverted to its default network configuration where it wants a network like 192.168.1.0/24 or 192.168.0.0/24 (I don't remember which network). It seems to be rebooting over, and over, and over again (maybe doing a DHCPDISCOVER between reboots).

This device is still connected to the switch, and it seems to have a link connection between reboots.

Is there a way for me to probe the device from a computer which is attached to the same switch? Is there a layer 2 equivalent for the ping command, or a broadcast ping to show me all devices connected to this lan segment?

networking link-layer

3 Answers

  1. arping may be what you're looking for?

    • 5
  2. Best Answer

    You can attack this in various ways. First, try to find the technical manual for the device in question. That will hopefully tell you what exactly it uses for a default configuration.

    Then, remove the network switch from the equation if possible. Connect the device directly to a pc of some sort using a crossover cable. That way you can configure the pc to be on the network as you think the device is on, and see if you can talk to it. This also allows you to easily use a tool like tcpdump to watch what the device is sending over the wire. For example if I connect a device directly to the ethernet port on my mac with a crossover cable, I can do this:

    # tcpdump -i en0

    to see all the traffic coming from the device (note you have to be root, or run that command via sudo).

    Watching the tcpdump output should give you a very clear idea of what the non-responsive device is trying to do on the network.

    Note that I recommend connecting the device directly to your computer because of the way network switches work. The switch doesn't send traffic to your port if it's not destined for you. Thus the device could be chattering away but since your computer isn't on the same IP network you won't see most of the data. There are ways around this such as switch port mirroring, but in general it's simplest to just bypass the switch entirely.

    • 2

  3. In addition to arping, ping 255.255.255.255 and arp -na together may help.

    • 2