Re,
Nils Magnus wrote:
> 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.
>
Acceptable workaround and scriptable in Linux. Is there a command
line/programmatic way to change an interface netmask in Window$?
>
>>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).
Well, it happens in the (supposedly production) network setup I am
working in :) It is propably not the correct/proper behaviour and it
would be helpful if nmap could tell me that/let me explore the possibility.
>
> 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.
At the moment I am just capturing return traffic with ethereal and
pushing all ARP responses into a database where I can then filter out
what I don't need. So yes, if some other tool/process can do it, maybe
nmap code is not the place for this functionality.
>
> 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.
Agreed. An example is that in this simple DHCP case, nmap currently
"trusts" the DHCP server to supply the correct netmask for the interface
and manual intervention in the OS (and not a simple setting in nmap) is
required to work around this.
>
> Regards,
>
> Nils Magnus
> Program-Chair LinuxTag 2005 Free Conference Program
>
> LinuxTag 2005: Where .com meets .org - magnus_at_linuxtag.org
>
regards
jp
--
This message is subject to the CSIR's copyright, terms and conditions and
e-mail legal notice. Views expressed herein do not necessarily represent the
views of the CSIR.
CSIR E-mail Legal Notice
http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html
CSIR Copyright, Terms and Conditions
http://mail.csir.co.za/CSIR_Copyright.html
For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line to
HelpDesk_at_csir.co.za.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Received on Oct 11 2005
Intro
