scan for machines in the subnet

I wonder what is the easiest and fastest way to detect all machines in the
current subnet from one of the machines and get their MAC-adresses.

My first approach would be to ping each possible adress and then read the
arp-table for valid mac's.

But assuming my limited knowledge of arp and other protocol-layers I guess there
are much better ways.

I tried a broadcast-ping on the subnet (ping -b 10.21.1.0) but to my suprise it
did not make all machines respond.

The more sophisticated question (and not acutally part of my task to keep tracks
and logs of all machines in a WLAN-network) is if there is a way to detect
machines that does not respond to ICMP-requests like ping.
One could use tools like nmap on each possible adress and every port, but this
would take a lot of time.
Maybe there is a protokoll/layer (like arp?) that makes every networkcard
respond to certain requests.

Any help is greatly appretiated. And excuse for possible stupid assumptions in
my posting. I usually think I know a lot about networks cause I play with
servers every day, but when it comes to questions that exceeed the terms
"ip-adress" and "port" I realize pretty soon that in fact I know nothing.

thnx
peter





peter pilsl

On Thu, 01 Mar 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <d6514$45e70589$557d99cd$(E-Mail Removed)>, peter pilsl wrote:

>I wonder what is the easiest and fastest way to detect all machines in
>the current subnet from one of the machines and get their MAC-adresses.

Ask the network administrator? Or is that you? ;-)

>My first approach would be to ping each possible adress and then read
>the arp-table for valid mac's.

Assuming there isn't a router between you and the net you are looking at
and if there is one it's not blocking pings, this it probably the easiest
way.

>But assuming my limited knowledge of arp and other protocol-layers I
>guess there are much better ways.

Well... if you are on a switched (not hub or coax) network, and the switch
has intelligence (and you have access to that switch), a faster way would
be to look at the management tables in the switch - much the same as an
ARP cache, except that the switch should know where everyone is (which
implies it knows MAC and IP address).

There may be other systems that ignore the recommendations in RFC1122
section 2.3.2 (which recommends a cache timeout of one minute) and have
longer timeouts - one example would be a Cisco router. Depending on how
they are configured, they _may_ have an ARP cache timeout up to an hour
or two - making it much more likely that they have the data in cache.

>I tried a broadcast-ping on the subnet (ping -b 10.21.1.0) but to my
>suprise it did not make all machines respond.

Two reasons - some O/S ignore broadcast pings, to discourage the practice
(which can be a denial of service mechanism). Also, many systems can be
configured to ignore pings - broadcast _or_ unicast.

>The more sophisticated question (and not acutally part of my task to
>keep tracks and logs of all machines in a WLAN-network) is if there is
>a way to detect machines that does not respond to ICMP-requests like
>ping.

[compton ~]$ whatis arping arpwatch hping2 nmap
arping (8) - sends arp and/or ip pings to a given host
arpwatch (8) - keep track of ethernet/ip address pairings
hping2 (8) - send (almost) arbitrary TCP/IP packets to network hosts
nmap (1) - Network exploration tool and security scanner
[compton ~]$

You have to be in "the right place" on the network topology, such as a
switch, or the routers, or some critical server that everyone is going to
use, but an ARP watching tool is probably the best bet. Reason is that
with _rare_ exceptions ('man ifconfig' - look at the '-arp' option, or
'man ip' and look for the string 'arp'), ARP is needed to establish a
communication on Ethernet - the packets are moved using the MAC address,
not the IP. Thus, even if a remote host has a firewall that is DROPping
all traffic (UDP, ICMP, TCP, or any of the 130+ other protocols that
can be found in an IP packet), it will still respond to an ARP request.
Doesn't matter how you cause the packet to be generated (ping, traceroute,
telnet, or what-ever) - you need only cause your kernel to try to send
something to that host, and before that can happen, your kernel must
have the MAC/IP relationship data in it's ARP cache.

Note - this will not find unconfigured or misconfigured systems. I could
set my Network Analyzer with an address on a "different" network, and
(unless I do something st00pid) you wouldn't find it unless you knew the
right IP address to ARP for.

>One could use tools like nmap on each possible adress and every port,
>but this would take a lot of time.

Each address, yes - but ports (and IP protocols) are irrelevant.

>Maybe there is a protokoll/layer (like arp?) that makes every networkcard
>respond to certain requests.

ARP - unless you've disabled it on your system because you've hard-coded
the ARP cache.

>Any help is greatly appretiated. And excuse for possible stupid
>assumptions in my posting. I usually think I know a lot about networks
>cause I play with servers every day, but when it comes to questions that
>exceeed the terms "ip-adress" and "port" I realize pretty soon that in
>fact I know nothing.

Do you have access to a technical library - perhaps a college/university
book store? The "standard" reference book is W. Richard Stevens "TCP/IP
Illustrated, Volume 1 - the protocols" from Addison-Wesley (1996, ISBN
0-201-63346-9, 576 pgs). You can also learn by using a packet sniffer,
but where you locate this depends on the layout of your network. The
modern Ethernet uses switches rather than hubs or coax, and these only
send broadcast packets (such as ARP) to all hosts, while unicast packets
only go to the destination computer - not everyone.

Old guy

In news:d6514$45e70589$557d99cd$(E-Mail Removed),
peter pilsl <(E-Mail Removed)> wrote:

> One could use tools like nmap on each possible adress and every port,
> but this would take a lot of time.

It would?

nmap -sS -p0 192.168.0.0/24

returns the MAC of 256 IP addresses in just a few seconds.

peter pilsl wrote:
>
> I wonder what is the easiest and fastest way to detect all machines in
> the current subnet from one of the machines and get their MAC-adresses.
>
> My first approach would be to ping each possible adress and then read
> the arp-table for valid mac's.
>
> But assuming my limited knowledge of arp and other protocol-layers I
> guess there are much better ways.

Trying to do this from a client on the network is an error prone way.
You will never be guaranteed to find all of the hosts.

A "better" way is to query the switch itself. Many switches
will have the ability to get this information from the MIB via
SNMP. That's the "better" way.

On Sun, 04 Mar 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <(E-Mail Removed)>, Chris Cox wrote:

>peter pilsl wrote:
>
>> I wonder what is the easiest and fastest way to detect all machines in
>> the current subnet from one of the machines and get their MAC-adresses.
>>
>> My first approach would be to ping each possible adress and then read
>> the arp-table for valid mac's.

>Trying to do this from a client on the network is an error prone way.
>You will never be guaranteed to find all of the hosts.

The only hosts that won't be found are those that have disabled ARP on
their network setup, OR are using off-network IP addresses that you did
not try to talk to. ARP is lower in the stack than firewall code, and
even if a host is dropping all TCP, UDP, or ICMP (etc.) packets, it will
still respond to an ARP packet addressed to it's IP address.

>A "better" way is to query the switch itself. Many switches
>will have the ability to get this information from the MIB via
>SNMP. That's the "better" way.

No disagreement - and if your switch won't provide that information, then
querying your router's ARP cache is probably second best - indeed any
host that the remote is likely to talk to. We were sweeping the ARP cache
of the routers and the servers on each segment at regular intervals 24/7
before we got our first Etherswitch in 1995, looking for rogue addresses.

Old guy

Moe Trin wrote:
> On Sun, 04 Mar 2007, in the Usenet newsgroup comp.os.linux.networking, in
> article <(E-Mail Removed)>, Chris Cox wrote:
>
>> peter pilsl wrote:
>>
>>> I wonder what is the easiest and fastest way to detect all machines in
>>> the current subnet from one of the machines and get their MAC-adresses.
>>>
>>> My first approach would be to ping each possible adress and then read
>>> the arp-table for valid mac's.
>
>> Trying to do this from a client on the network is an error prone way.
>> You will never be guaranteed to find all of the hosts.
>
> The only hosts that won't be found are those that have disabled ARP on
> their network setup, OR are using off-network IP addresses that you did
> not try to talk to. ARP is lower in the stack than firewall code, and
> even if a host is dropping all TCP, UDP, or ICMP (etc.) packets, it will
> still respond to an ARP packet addressed to it's IP address.

A switch on a meshed network can reply to ARP with it's own MAC.

>
>> A "better" way is to query the switch itself. Many switches
>> will have the ability to get this information from the MIB via
>> SNMP. That's the "better" way.
>
> No disagreement - and if your switch won't provide that information, then
> querying your router's ARP cache is probably second best - indeed any
> host that the remote is likely to talk to. We were sweeping the ARP cache
> of the routers and the servers on each segment at regular intervals 24/7
> before we got our first Etherswitch in 1995, looking for rogue addresses.
>
> Old guy

Chris Cox wrote:
> Moe Trin wrote:
>> On Sun, 04 Mar 2007, in the Usenet newsgroup comp.os.linux.networking, in
>> article <(E-Mail Removed)>, Chris Cox wrote:
>>
>>> peter pilsl wrote:
>>>
>>>> I wonder what is the easiest and fastest way to detect all machines in
>>>> the current subnet from one of the machines and get their MAC-adresses.
>>>>
>>>> My first approach would be to ping each possible adress and then read
>>>> the arp-table for valid mac's.
>>> Trying to do this from a client on the network is an error prone way.
>>> You will never be guaranteed to find all of the hosts.
>> The only hosts that won't be found are those that have disabled ARP on
>> their network setup, OR are using off-network IP addresses that you did
>> not try to talk to. ARP is lower in the stack than firewall code, and
>> even if a host is dropping all TCP, UDP, or ICMP (etc.) packets, it will
>> still respond to an ARP packet addressed to it's IP address.
>
> A switch on a meshed network can reply to ARP with it's own MAC.
>

I've just run Patrick's nmap scan on our office network, and I don't see
any indication that our switches are modifying the MACs, based on nmap's
partial identification of the companies owning the MAC addresses found.

I would have thought that a switch would not modify the MAC - after all,
it would mess up things like statically assigned IP addresses issued by
a DHCP server.

Hello,

Moe Trin a écrit :
>>
>>>I wonder what is the easiest and fastest way to detect all machines in
>>>the current subnet from one of the machines and get their MAC-adresses.
>>>
>>>My first approach would be to ping each possible adress and then read
>>>the arp-table for valid mac's.
>
>>You will never be guaranteed to find all of the hosts.
>
> The only hosts that won't be found are those that have disabled ARP on
> their network setup, OR are using off-network IP addresses that you did
> not try to talk to.

Or those that don't use IPv4 at all.

> ARP is lower in the stack than firewall code

Lower than *IP* firewall code. But there can be ARP firewall code, e.g.
arptables.

On Mon, 05 Mar 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <45ebf363$0$24618$(E-Mail Removed)>, David Brown wrote:

>Chris Cox wrote:

>> Moe Trin wrote:

>>> The only hosts that won't be found are those that have disabled ARP on
>>> their network setup, OR are using off-network IP addresses that you did
>>> not try to talk to. ARP is lower in the stack than firewall code, and
>>> even if a host is dropping all TCP, UDP, or ICMP (etc.) packets, it will
>>> still respond to an ARP packet addressed to it's IP address.
>>
>> A switch on a meshed network can reply to ARP with it's own MAC.
>
>I've just run Patrick's nmap scan on our office network, and I don't see
>any indication that our switches are modifying the MACs, based on nmap's
>partial identification of the companies owning the MAC addresses found.

Note he wrote "can", and not "will". Generally speaking, those switches
that do substitute the MAC will have intelligence and will provide access
(possibly through SNMP - possibly via other protocols) to their internal
table of "who is on which port".

>I would have thought that a switch would not modify the MAC - after all,
>it would mess up things like statically assigned IP addresses issued by
>a DHCP server.

True - but if you're going to statically assign IP addresses, why not do
so directly? It usually takes less time to do so.

Old guy

Moe Trin wrote:
> On Mon, 05 Mar 2007, in the Usenet newsgroup comp.os.linux.networking, in
> article <45ebf363$0$24618$(E-Mail Removed)>, David Brown wrote:
>
>> Chris Cox wrote:
>
>>> Moe Trin wrote:
>
>>>> The only hosts that won't be found are those that have disabled ARP on
>>>> their network setup, OR are using off-network IP addresses that you did
>>>> not try to talk to. ARP is lower in the stack than firewall code, and
>>>> even if a host is dropping all TCP, UDP, or ICMP (etc.) packets, it will
>>>> still respond to an ARP packet addressed to it's IP address.
>>> A switch on a meshed network can reply to ARP with it's own MAC.
>> I've just run Patrick's nmap scan on our office network, and I don't see
>> any indication that our switches are modifying the MACs, based on nmap's
>> partial identification of the companies owning the MAC addresses found.
>
> Note he wrote "can", and not "will". Generally speaking, those switches
> that do substitute the MAC will have intelligence and will provide access
> (possibly through SNMP - possibly via other protocols) to their internal
> table of "who is on which port".
>
>> I would have thought that a switch would not modify the MAC - after all,
>> it would mess up things like statically assigned IP addresses issued by
>> a DHCP server.
>
> True - but if you're going to statically assign IP addresses, why not do
> so directly? It usually takes less time to do so.
>

There are a few reasons. In the past, I've directly assigned IP
addresses for servers and the like - as you say, it's the easiest method
(no need to copy MAC addresses between leases files and config files).
However, sometimes things change on a network - dns servers, networks,
etc. They don't change often, fortunately - but I'm reconfiguring
things at the moment (well, I'm planning it - when I've got my new
firewall and router set up, I'll do the reconfiguring), and that means
each manually configured server, workstation and printer must be
changed. Printers in particular can be conveniently given an address by
the DHCP server, and that address can be locked in the DHCP server's
configuration, so that addresses are consistent thereafter.

I guess my main concern about a switch messing with MAC addresses is to
be sure that each PC (or other device) on the network has the same MAC
address every time. It doesn't really matter if the apparent MAC
address for a PC is its true MAC address, or some switch-modified
version, as long as it is always the same and always unique.

mvh.,

David

> Old guy
>