Nmap Development mailing list archives

Re: Problems with nmap with openvz or bridge interfaces


From: Djalal Harouni <tixxdz () opendz org>
Date: Sat, 21 Jul 2012 12:02:15 +0100

On Sat, Jul 21, 2012 at 12:38:22AM -0700, David Fifield wrote:
On Fri, Jun 22, 2012 at 02:16:15PM +0100, Djalal Harouni wrote:
On Wed, Jun 20, 2012 at 07:54:14PM -0700, David Fifield wrote:
Why should it fail, just because of a lack of a MAC address? That should
be fine; we use raw sockets, not Ethernet, by default on Linux.
Hi David,

Thanks for the response I'll get back to this thread soon.
Need some time to test venet support and Nmap features on it, and to fix
other network interfaces and routes problems related to (2).

I did what you suggested and added support for ARPHRD_VOID in r29287. I
tested the change using the Owl 3.0 live CD, which starts with a venet0
interface.
Thanks David for the fix.

My concern is that libdnet automatically flags this interface as an
ethernet one which is not true, and later Nmap depends on this flag to
send ethernet frames.


IIRC when I took a look at how libdnet flags interfaces as ethernet ones I
found it not perfect! if the BROADCAST flag is set then this is ethernet.
see: libdnet-stripped/src/intf.c:_intf_set_type()

Some Linux virtual interfaces will have the BROADCAST flag set.


Now I'm not sure how Nmap and all the code path we have will deal with:
 if ethernet_dev => send ethernet frames...



So I was thinking that the correct behaviour is to make libdnet check the
address family and flag these interfaces as others, but I'm not sure
about the downsides of using the 'devt_other' type, will Nmap/NSE...
disable some scans that are perhaps supported by that device ?
and how we deal with other systems, are address family numbers portable ?


Anyway lets just do it David, and see if users report something...



Some raw notes for Fyodor and the changelog:

1) libdnet will flag interfaces as ethernet based on the BROADCAST flag.
   Fix: we should also check the address family and see if it's an
   ethernet device. Every operating system have its own *special*
   *expanded* address family numbers that are used to set the appropriate
   type of these virtual devices.


2) Set the appropriate type as described in (1) and add another "supported
   scans" tag to the "./nmap --iflist" output:

   *******************Nmap Supported Scans*****************
   DEV    (SHORT)       TYPE           Support
   lo     lo            loopback       partial
   eth0   eth0          ethernet       full
   xxx    xxx           other          unknown (or partial?)


The current behaviour:
3) Let libdnet to flag all these interfaces as ethernet, perhaps users
   will be able to run some scans that are supported by that special
   device, this will not be the case if libdnet flags them as others.
   
   But what about: users are trying to send ethernet frames on a non
   ethernet device.
   Perhaps with this nmap-dev will receive more bug reports and the
   output of "./nmap --iflist" will not help to determine the cause since
   all these special interfaces are marked as 'ethernet'.


David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/

-- 
tixxdz
http://opendz.org
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


Current thread: