Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I seem to be having some odd results when running netdiscover on my home network. From the cable modem to my scanner (skipping a few peripherals), here's the basic layout:

The cable modem is connected to our router, which also serves as DHCP server and primary Wi-Fi AP.

From there (again, skipping peripherals) the connection goes to a LAN port on another router, which has been stripped of its router roles (DHCP, etc) and acts only as a secondary Wi-Fi AP.

My laptop is connected to the secondary AP, running Windows 7 x64.

I'm running netdiscover from a virtual machine on my laptop, which is running Backtrack Linux.

The virtual machine is connected to my network via a VirtualBox adapter, running in "bridged" mode.

The network's addresses are in the range of RFC 1918 address space.

So, I ran netdiscover on the Backtrack VM. Most of the addresses returned were pretty much as expected, except for two.

 IP            At MAC Address      Count    Len   MAC Vendor                   
 -----------------------------------------------------------------------------     00:17:9a:8f:69:cf    01    060   D-Link Corporation        00:17:9a:8f:69:d0    01    060   D-Link Corporation           

I've got a fairly solid guess as to what this is - a D-Link VoIP router that we're only leaving connected (hard-line to the router) for its VoIP functions. The IP address looks like it may be a factory default (I'll be troubleshooting that another time) for the device.

What's I'm scratching my head over now is: Why was the D-Link device at able to receive and return the ARP packets across a 10.x.x.x network?

share|improve this question
Just as I finished writing this, I think I've gotten my head wrapped around it. But, for the sake of the community, I'd like to see what someone else will write up for it. – Iszi Nov 16 '11 at 0:42
up vote 5 down vote accepted

Unless you specifically state a range to use, netdiscover will scan for common networks, so this would include

An ARP request is broadcast at layer 2, so even though the backtrack PC is on a different IP network to the voip box, the arp request will still be seen and replied to. The request would be in the form of an ARP Probe, which does not contain an IP address to reply to - the reply is sent at layer 2 to the mac address of the device originating the request.

An ARP Probe is a method for determining whether an IP address is in use currently. It is usually used by a device prior to "claiming" an IP address, to ensure no one else on the local network is using it. It can however be used to see what addresses are being used on the local network, and seems likely that netdiscover would use it.

While an arp probe is part of the layer 3 IP protocol, it operates at layer 2. The packet looks a bit like this:

From MAC: <host mac address>, To MAC: ff:ff:ff:ff:ff:ff, Payload: "Is anyone using IP address"

So the destination mac is the broadcast mac address - all ones, it matches all addresses. Therefore any layer 2 device such as a switch, will broadcast it out of all ports in the same broadcast domain that the packet was received on. In a domestic router, this means all LAN ports (the lan ports on a domestic router are switchports). If any of the LAN ports are connected to another router's LAN ports, then the LAN ports are all in the same broadcast domain - the packet will be broadcast out of the port on the first router that is connected to the second router, the second router will see the packet is destined for ff:ff:ff:ff:ff:ff and so will broadcast it out of its own lan ports.

The point here is that a layer 2 broadcast packet will be seen by every device on the network, regardless of IP addresses.

So every device sees it. The voip device sees that it is an ARP probe, and that the IP address the sender is after matches the IP address it has configured, and so replies.

It cannot reply to the originating devices IP address, because the very nature of an ARP probe is that it is used by a device that does not yet have an IP address - it is used to see whether the IP address it wants is already in use. So the place in the packet where the senders IP address would ordinarily be is all zeroes.

And ARP probe reply is therefore sent to the MAC address of the sender.

share|improve this answer
I'm still not following how this would have happened. The ARP request/reply had to pass through two other layer 2(ish) devices. Shouldn't it have stopped along the way at one of them? Or am I not remembering my routing & switching principles properly? – Iszi Nov 16 '11 at 1:14
If the "routers" are all connected to each other via their switch ports, then they are effectively switches - no routing is taking place, so all at layer 2 in the same broadcast domain. – Paul Nov 16 '11 at 1:15
Looks like I'm not the only one that was slightly confused by this. Mind throwing in a little bit of Switching 101? – Iszi Nov 16 '11 at 14:07
The caveat here should be that I don't know specifically how netdiscover is doing its thing, but this is how it could work. I have updated my answer with more detail. I am happy to continue doing this until it is clear :) – Paul Nov 16 '11 at 22:26
Netdiscover pretty much just spams ARP requests to RFC 1918 addresses and shows what comes back. – Iszi Nov 16 '11 at 23:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .