Hello,

Timothy Murphy a écrit :
> goarilla <"kevin DOT paulus AT skynet DOT be"> wrote:
>
>>ping the broadcast address of your subnet
>
> Thanks, I found that pretty good:

This method is not very reliable, as many systems ignore broadcast ping
by default, including Windows and "recent" Linux kernels.

> -----------------------------------
> [root@alfred tim]# ping -c 2 -b 192.168.2.255
> WARNING: pinging broadcast address
> PING 192.168.2.255 (192.168.2.255) 56(84) bytes of data.
> 64 bytes from 192.168.2.12: icmp_seq=1 ttl=64 time=2.38 ms
> 64 bytes from 192.168.2.12: icmp_seq=2 ttl=64 time=0.898 ms

You got only one answer, that's not what I'd call "pretty good".

On Nov 8, 6:13 am, Timothy Murphy wrote:
> Steven Borrelli wrote:
> >> Is there an easy way to determine all the machines
> >> (or other devices) on a LAN?
>
> > Arpwatch is a pretty handy utility for this.
>
> >http://en.wikipedia.org/wiki/Arpwatch
>
> Thanks very much for the suggestion.
>
> I downloaded and installed arpwatch,
> and it works quite well,
> though it is rather strange,
> in that it does not display its output,
> but sends it to syslog (/var/log/messages in my case).
>
> Also it runs as a daemon,
> and keeps running once the command, eg "arpwatch -i eth1",
> is given.
>
> I suppose it is intended for administrative purposes
> on a large network.

If you are root, check your mail and you will probably see some
messages from arpwatch. That is one of arpwatch's ways of informing
you of changes in ARP entries on the network.

On Thu, 08 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <47330016$0$29259$ba620e4c@news.skynet.be>, goarilla wrote:

>Timothy Murphy wrote:

>> goarilla <"kevin DOT paulus AT skynet DOT be"> wrote:

>>> Maybe but i find the nmap manual page to be of very high quality and it
>>> includes a lot of information.
>>
>> Interesting how people differ.
>> "man nmap" _does_ give you a lot of information -
>> far too much, in my view.
>> I really don't want to read an encyclopedia
>> in order to find what command to give.

This is a problem you'll find with any "powerful" tool. It does a heck
of a lot of things, and there has to be someplace where it's explained.

[compton ~]$ man ls | wc
396 1654 15834
[compton ~]$ man find | wc
726 2406 22579
[compton ~]$

Care to check the size of the man page for 'bash'?

>> At least this man page does give some examples -
>> but they are all ludicrously complicated, in my view.

That's because it's a very complicated tool. But it's far from the only
one that would answer your question.

>>> I rather do man nmap '/sS' 'nn' (last two are less pager commands)
>>> to get to the section that discusses the half-open SYN scan than to
>>> follow some random howto.
>>
>> I don't know what the "half-open SYN scan" is,

It's another way of scanning

>> and don't really want to know. I just wanted to know what command
>> to give to find the devices on my lan.

ssh into the "managed switch" or router on your LAN, and look at the
ARP tables. There are literally dozens of ways to do this. You
could create a dumb shell script that attempts to connect to some
random port on each address on the LAN. While the script may provide
the needed answers directly, you can also monitor the ARP cache while
doing so - as even if the target has the port closed and/or is ignoring
all connection attempts, it _will_ still show up in the local ARP table
for 60 seconds. Which suggests yet another tool:

[compton ~]$ whatis arping
arping (8) - sends arp and/or ip pings to a given host
[compton ~]$

or even using tcpdump (or your favorite packet sniffer) to listen for
arp replies.

>ping the broadcast address of your subnet

Doesn't work on a lot of systems - either because the O/S ignores a
broadcast ping (avoid Denial Of Service attacks), or because the
individual system may have a firewall, or be configured to ignore
pings in general or just broadcast pings.

[compton ~]$ cat /proc/sys/net/ipv4/icmp_echo_ignore_all
1
[compton ~]$

>>> also if you execute nmap without args it'll print a pretty
>>> comprehensive list of options.
>>
>> Rather too comprehensive, for my purposes.

Versatile tools have lots of options.

>> I think the time has come when too much information
>> is almost as bad as too little.

That's always been the case. It's called 'information overload' and
has been cited as the cause of some aircraft accidents in the past.

Old guy