Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: libdnet problem with monitor mode interfaces
From: Djalal Harouni <tixxdz () opendz org>
Date: Tue, 29 May 2012 15:06:42 +0100

Hi Henri,

On Sun, May 27, 2012 at 10:31:08PM +0200, Henri Doreau wrote:
Hi,

nmap appears to fail at finding any interface when at least one of
them is in monitor mode.

"""
# ./nmap scanme.nmap.org
Starting Nmap 6.01 ( http://nmap.org ) at 2012-05-27 22:24 CEST
route_dst_netlink: can't find interface "wlan0"

Does it work as an unprivileged user ? can you try it please.

Perhaps a temporary workaround for those who only have root sessions
(on their devices...) is to let Nmap follow the unprivileged code path.

# ./nmap --unprivileged scanme.nmap.org

This should work.


# ./nmap --iflist scanme.nmap.org
Starting Nmap 6.01 ( http://nmap.org ) at 2012-05-27 22:24 CEST
INTERFACES: NONE FOUND(!)
ROUTES: NONE FOUND(!)

# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:26:B9:08:03:F1
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:17

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:4170 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4170 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:763856 (745.9 KiB)  TX bytes:763856 (745.9 KiB)

mon1      Link encap:UNSPEC  HWaddr
00-22-FB-D4-5F-34-D3-9F-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:754779 errors:0 dropped:775551 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:113748840 (108.4 MiB)  TX bytes:0 (0.0 b)

wlan0     Link encap:Ethernet  HWaddr 00:22:FB:D4:5F:34
          inet addr:10.0.16.185  Bcast:10.7.255.255  Mask:255.248.0.0
          inet6 addr: fe80::222:fbff:fed4:5f34/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:400862 errors:0 dropped:0 overruns:0 frame:0
          TX packets:341104 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:501491067 (478.2 MiB)  TX bytes:37946903 (36.1 MiB)

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.7.255.254    0.0.0.0         UG    0      0        0 wlan0
10.0.0.0        0.0.0.0         255.248.0.0     U     2      0        0 wlan0
"""

I can reliably reproduce this and traced the problem to
libdnet-stripped/src/intf.c, line 517. It returns -1 on an interface
in monitor mode and breaks out of the interface discovery loop.
Thanks.

Not sure how to fix cleanly, but ignoring the return code of
addr_ston() line 516 makes it work.
Ok, it seems for the monitor mode the address family will be
set to ARPHRD_IEEE80211_RADIOTAP == 803 [1] which is not supported by
addr_ston().

We could replace that addr_ston() in _intf_get_noalias() by:
 memcpy(&entry->intf_link_addr.addr_eth, &ifr.ifr_addr.sa_data, ETH_ADDR_LEN)


But from the above and from other checks like the 'IFF_IPMP' flag check,
I think that we should go for a better solution in intf_loop():

Do not break when _intf_get_noalias() fails, instead of that jump to the
next iteration, and return only if the callback fails. At least this will
save the long scans.

If we do this what are the downsides ? hide interfaces where Nmap might
work ? what about this ARPHRD_IEEE80211_RADIOTAP, other tools use it ?


For those who want a temporary fix, a quick patch is attached that will
work on Linux compiled with LINUX_PROCFS support. It will ignore other
special interface setups (aliases are not supported).

And this will only work if you add another wireless interface [2]


Thanks.

Regards.

[1] www.radiotap.org/
[2] http://linuxwireless.org/en/users/Documentation/iw#Adding_interfaces_with_iw

-- 
tixxdz
http://opendz.org

Attachment: nmap_libdnet_continue.diff
Description:

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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault