Re: libdnet problem with monitor mode interfaces

[David Fifield <david () bamsoftware com>]

On Tue, May 29, 2012 at 03:06:42PM +0100, Djalal Harouni wrote:
> > 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)

Thank you for finding this. I replied in a different message that I
think rather that support for ARPHRD_IEEE80211_RADIOTAP should be added
to addr_ston.

> 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).

I'm not sure about this fix. I considered the same thing, but I'm a bit
worried about unknown side effects. One thing is that error reporting is
more difficult from libdnet because we don't have access to Nmap's
logging functions. So sometimes a failure like this is the only way we
get bug reports. If the code were already the way you suppose, we would
never know that ARPHRD_IEEE80211_RADIOTAP interfaces are being ignored.

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