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 10.0.0.0/8 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
-----------------------------------------------------------------------------
192.168.2.1 00:17:9a:8f:69:cf 01 060 D-Link Corporation
192.168.2.1 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 192.168.2.1 able to receive and return the ARP packets across a 10.x.x.x network?
Answer
Unless you specifically state a range to use, netdiscover
will scan for common networks, so this would include 192.168.0.0/16.
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: , To MAC: ff:ff:ff:ff:ff:ff, Payload: "Is anyone using IP address 192.168.1.1"
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.
Comments
Post a Comment