f



arp-scan

Hi All,

   "arp-scan -l" is an interesting way to find folks
on your network (for example, 192.168.1.0/24), but
it won't find

    1) your adapter

    2) folks on your Ethernet, but with a different
       network.  For example, you are on 192.168.1.0/24
       and they are on 10.0.0.0/24

Hmmmmmm.  I wish Auto Scan was still supported.

-T
0
T
12/24/2016 12:34:32 AM
comp.os.linux.misc 33599 articles. 1 followers. amosa69 (78) is leader. Post Follow

16 Replies
681 Views

Similar Articles

[PageSpeed] 39

Le 24/12/2016 à 01:34, T a écrit :
>
>   "arp-scan -l" is an interesting way to find folks
> on your network (for example, 192.168.1.0/24), but
> it won't find
>
>    1) your adapter

There are other - and easier - means to find this information.

>    2) folks on your Ethernet, but with a different
>       network.  For example, you are on 192.168.1.0/24
>       and they are on 10.0.0.0/24

If you know the subnets used on your LAN, you can specify them in the 
command line instead of -l. Unless you tell it to scan the full IPv4 
range, no active scanner can find all hosts on a network.

Also, an ARP scanner can find only hosts which speak IPv4/ARP, not those 
which speak only IPv6, PPPoE or whatever.
0
Pascal
12/24/2016 9:13:07 AM
On 24/12/16 11:13, Pascal Hambourg wrote:
> Unless you tell it to scan the full IPv4 range, no active scanner can
> find all hosts on a network.

Wrong.

Nearly all active stacks will respond to an *Ethernet* broadcast.

That want propagate via routed links, but often that's what you want.

The networking library is protocol independenet. C and Ethernet  was 
there before TCP/IP...or at least they developed separately.

I suspect Autoscan-network used ethernet broadcast and inspected packets 
resulting from that to ID what hosts there were on what MAC addresses 
and possibly what protocols they expected to use.

Code for a protocol agnostic Ethernet packet sniffer exists out there, 
as I found some.

I am not sufficiently au fait, however, with what other network stacks 
do when they are broadcast at, to hazard the rest of the code meeded to 
duplicate autoscan-networks functionality..

If that is the purpose behind the OP question.
0
The
12/24/2016 9:44:27 AM
Le 24/12/2016 à 10:44, The Natural Philosopher a écrit :
> On 24/12/16 11:13, Pascal Hambourg wrote:
>> Unless you tell it to scan the full IPv4 range, no active scanner can
>> find all hosts on a network.
>
> Wrong.
>
> Nearly all active stacks will respond to an *Ethernet* broadcast.

What kind of ethernet broadcast ? Using what protocol and payload ?
0
Pascal
12/24/2016 10:33:24 AM
On 24/12/16 11:44, The Natural Philosopher wrote:
> On 24/12/16 11:13, Pascal Hambourg wrote:
>> Unless you tell it to scan the full IPv4 range, no active scanner can
>> find all hosts on a network.
>
> Wrong.
>
> Nearly all active stacks will respond to an *Ethernet* broadcast.
>
> That want propagate via routed links, but often that's what you want.
>
> The networking library is protocol independenet. C and Ethernet  was
> there before TCP/IP...or at least they developed separately.
>
> I suspect Autoscan-network used ethernet broadcast and inspected packets
> resulting from that to ID what hosts there were on what MAC addresses
> and possibly what protocols they expected to use.
>
> Code for a protocol agnostic Ethernet packet sniffer exists out there,
> as I found some.
>
> I am not sufficiently au fait, however, with what other network stacks
> do when they are broadcast at, to hazard the rest of the code meeded to
> duplicate autoscan-networks functionality..
>
> If that is the purpose behind the OP question.
RFC826 and friends is worth a look...

0
The
12/24/2016 12:34:23 PM
On 24/12/16 12:33, Pascal Hambourg wrote:
> Le 24/12/2016 à 10:44, The Natural Philosopher a écrit :
>> On 24/12/16 11:13, Pascal Hambourg wrote:
>>> Unless you tell it to scan the full IPv4 range, no active scanner can
>>> find all hosts on a network.
>>
>> Wrong.
>>
>> Nearly all active stacks will respond to an *Ethernet* broadcast.
>
> What kind of ethernet broadcast ? Using what protocol and payload ?

ethernet.

ARP.


0
The
12/24/2016 12:34:58 PM
Le 24/12/2016 à 13:34, The Natural Philosopher a écrit :
> RFC826 and friends is worth a look...

AFAICS, that's about ARP. It's not protocol agnostic.

0
Pascal
12/24/2016 12:58:49 PM
Le 24/12/2016 à 13:34, The Natural Philosopher a écrit :
> On 24/12/16 12:33, Pascal Hambourg wrote:
>> Le 24/12/2016 à 10:44, The Natural Philosopher a écrit :
>>> On 24/12/16 11:13, Pascal Hambourg wrote:
>>>> Unless you tell it to scan the full IPv4 range, no active scanner can
>>>> find all hosts on a network.
>>>
>>> Wrong.
>>>
>>> Nearly all active stacks will respond to an *Ethernet* broadcast.
>>
>> What kind of ethernet broadcast ? Using what protocol and payload ?
>
> ethernet.

I mean the protocol inside the ethernet frame, specified in the 
EtherType header field.

> ARP.

Works only for IPv4 and other protocols which use it.
0
Pascal
12/24/2016 1:01:07 PM
On 24/12/16 14:58, Pascal Hambourg wrote:
> Le 24/12/2016 à 13:34, The Natural Philosopher a écrit :
>> RFC826 and friends is worth a look...
>
> AFAICS, that's about ARP. It's not protocol agnostic.
>
Go back and read it again.

0
The
12/24/2016 1:22:35 PM
On 24/12/16 15:01, Pascal Hambourg wrote:
> Le 24/12/2016 à 13:34, The Natural Philosopher a écrit :
>> On 24/12/16 12:33, Pascal Hambourg wrote:
>>> Le 24/12/2016 à 10:44, The Natural Philosopher a écrit :
>>>> On 24/12/16 11:13, Pascal Hambourg wrote:
>>>>> Unless you tell it to scan the full IPv4 range, no active scanner can
>>>>> find all hosts on a network.
>>>>
>>>> Wrong.
>>>>
>>>> Nearly all active stacks will respond to an *Ethernet* broadcast.
>>>
>>> What kind of ethernet broadcast ? Using what protocol and payload ?
>>
>> ethernet.
>
> I mean the protocol inside the ethernet frame, specified in the
> EtherType header field.
>
>> ARP.
>
> Works only for IPv4 and other protocols which use it.
'other protocols that use it' being just about every protocol that works 
over ethernet at all.

almost all protocols that use ethernet use a version of ARP.
I cant think of a single ethernet protocal that doesnt have some hghet 
level than MCA sdeessing scheme: You need ARP to conext that to a MAC 
level address.

Its not beyond the realms of possibility to broadast the half diozen 
protocol types that will cover them and interpret the one per device 
responses.

In fact IIRC you can cover most things with DECNET, NETBEUI, IPX/SPX 
Appletalk and TCP/IP. There's a couple of others like Chaosnet IIRC but 
when was the last time you saw that?

0
The
12/24/2016 1:30:03 PM
Le 24/12/2016 à 14:30, The Natural Philosopher a écrit :
> On 24/12/16 15:01, Pascal Hambourg wrote:
>> Le 24/12/2016 à 13:34, The Natural Philosopher a écrit :
>>> On 24/12/16 12:33, Pascal Hambourg wrote:
>>>> Le 24/12/2016 à 10:44, The Natural Philosopher a écrit :
>>>>> On 24/12/16 11:13, Pascal Hambourg wrote:
>>>>>> Unless you tell it to scan the full IPv4 range, no active scanner can
>>>>>> find all hosts on a network.
>>>>>
>>>>> Wrong.
>>>>>
>>>>> Nearly all active stacks will respond to an *Ethernet* broadcast.
>>>>
>>>> What kind of ethernet broadcast ? Using what protocol and payload ?
>>>
>>> ethernet.
>>
>> I mean the protocol inside the ethernet frame, specified in the
>> EtherType header field.
>>
>>> ARP.
>>
>> Works only for IPv4 and other protocols which use it.
>
> 'other protocols that use it' being just about every protocol that works
> over ethernet at all.
>
> almost all protocols that use ethernet use a version of ARP.

"Almost" ? IPv4 is the only protocol I use that uses ARP.
IPv6 uses ICMPv6 multicast for neighbour discovery.
PPPoE uses PADI/PADO for access concentrator discovery.

Even though, I don't get your point.

- An IPv4 host will only respond to an ARP request for its own IP 
address, so you must scan all the range.
- An IPv6 host will only respond to an ICMPv6 Neighbour Solicitation 
request for its own IP address, so you must scan all the range (may 
recall that IPv6 subnets are huge ?).
- Only a PPPoE access concentrator will respond to PADI requests.

> I cant think of a single ethernet protocal that doesnt have some hghet
> level than MCA sdeessing scheme: You need ARP to conext that to a MAC
> level address.

Could you rewrite this without the typoes ?
0
Pascal
12/24/2016 6:14:02 PM
Le 24/12/2016 à 14:22, The Natural Philosopher a écrit :
> On 24/12/16 14:58, Pascal Hambourg wrote:
>> Le 24/12/2016 à 13:34, The Natural Philosopher a écrit :
>>> RFC826 and friends is worth a look...
>>
>> AFAICS, that's about ARP. It's not protocol agnostic.
>>
> Go back and read it again.

No, thanks.

I'm not going to lose time reading it in detail unless you explain first 
what is your point with this document and how it helps finding all hosts 
on a network.

0
Pascal
12/24/2016 6:16:10 PM
On 24/12/16 20:16, Pascal Hambourg wrote:
> Le 24/12/2016 à 14:22, The Natural Philosopher a écrit :
>> On 24/12/16 14:58, Pascal Hambourg wrote:
>>> Le 24/12/2016 à 13:34, The Natural Philosopher a écrit :
>>>> RFC826 and friends is worth a look...
>>>
>>> AFAICS, that's about ARP. It's not protocol agnostic.
>>>
>> Go back and read it again.
>
> No, thanks.
>
> I'm not going to lose time reading it in detail unless you explain first
> what is your point with this document and how it helps finding all hosts
> on a network.
>
Your loss then

0
The
12/24/2016 7:49:53 PM
On 24/12/16 20:14, Pascal Hambourg wrote:
> Le 24/12/2016 à 14:30, The Natural Philosopher a écrit :
>> On 24/12/16 15:01, Pascal Hambourg wrote:
>>> Le 24/12/2016 à 13:34, The Natural Philosopher a écrit :
>>>> On 24/12/16 12:33, Pascal Hambourg wrote:
>>>>> Le 24/12/2016 à 10:44, The Natural Philosopher a écrit :
>>>>>> On 24/12/16 11:13, Pascal Hambourg wrote:
>>>>>>> Unless you tell it to scan the full IPv4 range, no active scanner
>>>>>>> can
>>>>>>> find all hosts on a network.
>>>>>>
>>>>>> Wrong.
>>>>>>
>>>>>> Nearly all active stacks will respond to an *Ethernet* broadcast.
>>>>>
>>>>> What kind of ethernet broadcast ? Using what protocol and payload ?
>>>>
>>>> ethernet.
>>>
>>> I mean the protocol inside the ethernet frame, specified in the
>>> EtherType header field.
>>>
>>>> ARP.
>>>
>>> Works only for IPv4 and other protocols which use it.
>>
>> 'other protocols that use it' being just about every protocol that works
>> over ethernet at all.
>>
>> almost all protocols that use ethernet use a version of ARP.
>
> "Almost" ? IPv4 is the only protocol I use that uses ARP.
> IPv6 uses ICMPv6 multicast for neighbour discovery.
> PPPoE uses PADI/PADO for access concentrator discovery.
>
> Even though, I don't get your point.
>
> - An IPv4 host will only respond to an ARP request for its own IP
> address, so you must scan all the range.
> - An IPv6 host will only respond to an ICMPv6 Neighbour Solicitation
> request for its own IP address, so you must scan all the range (may
> recall that IPv6 subnets are huge ?).
> - Only a PPPoE access concentrator will respond to PADI requests.
>
>> I cant think of a single ethernet protocal that doesnt have some hghet
>> level than MCA sdeessing scheme: You need ARP to conext that to a MAC
>> level address.
>
> Could you rewrite this without the typoes ?

I could, but I've decided not to bother.
pearls/swine/before


Not sure that the plural of typo is typoes, either.

0
The
12/24/2016 7:52:44 PM
Le 24/12/2016 à 20:52, The Natural Philosopher a écrit :
> On 24/12/16 20:14, Pascal Hambourg wrote:
>> Le 24/12/2016 à 14:30, The Natural Philosopher a écrit :
>>
>>> I cant think of a single ethernet protocal that doesnt have some hghet
>>> level than MCA sdeessing scheme: You need ARP to conext that to a MAC
>>> level address.
>>
>> Could you rewrite this without the typoes ?
>
> I could, but I've decided not to bother.
> pearls/swine/before

It's not very respectful towards me who tried to decipher what you wrote 
despite some words were unrecognizable.

> Not sure that the plural of typo is typoes, either.

Is it really only what matters to you ? How sad.
0
Pascal
12/24/2016 8:12:51 PM
Le 24/12/2016 à 20:49, The Natural Philosopher a écrit :
> On 24/12/16 20:16, Pascal Hambourg wrote:
>> Le 24/12/2016 à 14:22, The Natural Philosopher a écrit :
>>> On 24/12/16 14:58, Pascal Hambourg wrote:
>>>> Le 24/12/2016 à 13:34, The Natural Philosopher a écrit :
>>>>> RFC826 and friends is worth a look...
>>>>
>>>> AFAICS, that's about ARP. It's not protocol agnostic.
>>>>
>>> Go back and read it again.
>>
>> No, thanks.
>>
>> I'm not going to lose time reading it in detail unless you explain first
>> what is your point with this document and how it helps finding all hosts
>> on a network.
>>
> Your loss then

Do you expect I will consider you seriously after you admitted in 
another post that you didn't read it yourself ?

"I posted an RFC for the generaic ARP style probe, but didn't read it."
0
Pascal
12/24/2016 8:16:06 PM
On Sat, 24 Dec 2016, in the Usenet newsgroup comp.os.linux.misc, in article
<o3lre9$2g77$1@saria.nerim.net>, Pascal Hambourg wrote:

> Le 24/12/2016 à 13:34, The Natural Philosopher a écrit :

>> RFC826 and friends is worth a look...

> AFAICS, that's about ARP. It's not protocol agnostic.

It works for IPv4 _ONLY_ - IPv6 uses a different mechanism - never mind
the other _four_thousand_ plus protocols (most of which won't be seen
outside of the laboratory they were developed in) that are _registered_
to the IEEE (try http://standards.ieee.org/regauth/ethertype/eth.txt
for a listing).  The list translates the registered 16 bit Ether types
(the two bytes following the 48 bit hardware source data).  Of course,
how many networks are still carrying such protocols as the several
versions of Appletalk, Banyan Vines, LanTastic, microsoft NetBIOS, the
two versions of Novell Netware, OS/2 Lan Manager, TOPS, XNS - to name a
few.    Each of those network protocols had their own mechanism of
resolving MAC address to specific hosts, similar to RFC0826 but totally
incompatible.

        Old guy
0
Moe
12/24/2016 9:31:05 PM
Reply: