Re: ARP ping, netmask and fallback to ICMP

[magnus () linuxtag org (Nils Magnus)]

Re,

On Mon, Oct 10, 2005 at 05:02:10PM +0200, J.P. Delport wrote:

> I have been trying to ARP ping some hosts on a local ethernet segment.
> ARP pings get sent only when the IP addresses are on the same subnet as
> that of my network card (Win32 & Linux, class C). Short of changing the
> actual card netmask (a pain on Windows with DHCP enabled - lots of
> clicking), is there a way to force nmap to send ARP requests even when
> the targets are not on my subnet? (I know they are on my eth segment.)

Well, that is certainly possible, but is this really necessary? Usually
you can emulate that feature by assinging a suitably small netmask to
your interface as you suggested. I think that's a fair trade-off
compared to the additional complexity in the code necessary otherwise.
 
> When I force the variable directly_connected to true in targets.cc's
> nexthost function, I can successfully send ARP requests to the hosts I
> am interested in, but then I run into the next problem: When sending an
> ARP to hosts not on my subnet, I get an ARP response from target hosts,
> but also from a switch actings as a proxy for them. nmap currently only
> stores one MAC address for the target - sometimes this is the target
> host and sometimes the proxy. Maybe it could be usefull to supply a MAC
> address that nmap ignores in ARP replies?

This is a fairly interesting setup. Does this actually work in an
production enironment? :) Well, receiving one answer per IP resolve
request at most is an implicit assumption in the ARP protocol and even
in your environment your IP stack should prevent your kernel from
requesting a resolution as long as you have the correct (intended
netmask).

However, why not filtering the "wrong" ARP responses from the gateway
with something like netfilter or some other firefall capacity? I think
that is again a much better solution compared to such a specific change
in the main code.

But you raise an important issue: nmap's power results from its flexible
uses _in_combination_ with other important OS level facilities. Tasks
that can be done easily with builtin means of the OS do not really need
to be duplicated or reimplemented into nmap, as maintenance is much
harder this way.

Regards,

Nils Magnus
Program-Chair LinuxTag 2005 Free Conference Program

LinuxTag 2005: Where .com meets .org - magnus () linuxtag org


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev