Machines on LAN - Networking

This is a discussion on Machines on LAN - Networking ; goarilla wrote: > ping the broadcast address of your subnet > usually 192.168.0.255, 192.168.1.255 or 192.168.8.255 > ping -c 2 -b > en then filter the arb tables to not include the incomplete info > /sbin/arp -a | grep -v ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 24 of 24

Thread: Machines on LAN

  1. Re: Machines on LAN

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

    > ping the broadcast address of your subnet
    > usually 192.168.0.255, 192.168.1.255 or 192.168.8.255
    > ping -c 2 -b
    > en then filter the arb tables to not include the incomplete info
    > /sbin/arp -a | grep -v 'incomplete'


    Thanks, I found that pretty good:
    -----------------------------------
    [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

    --- 192.168.2.255 ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 999ms
    rtt min/avg/max/mdev = 0.898/1.639/2.381/0.742 ms
    [root@alfred tim]# /sbin/arp -a | grep -v 'incomplete'
    blanche (192.168.2.7) at 00:0E:A6:AF:0B:11 [ether] on eth1
    ? (192.168.2.11) at 00:02:2D:27:218 [ether] on eth1
    ? (192.168.1.254) at 00:00:C5:C3:96:50 [ether] on eth0
    wrt (192.168.2.12) at 00:16:B6A:56:B2 [ether] on eth1
    -----------------------------------



  2. Re: Machines on LAN

    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".

  3. Re: Machines on LAN

    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.


  4. Re: Machines on LAN

    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

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2