Re: libdnet problem with monitor mode interfaces

[Djalal Harouni <tixxdz () opendz org>]

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/