mailing list archives
Re: libdnet problem with monitor mode interfaces
From: David Fifield <david () bamsoftware com>
Date: Tue, 29 May 2012 08:15:12 -0700
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  which is not supported by
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
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.
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/
Re: libdnet problem with monitor mode interfaces David Fifield (May 29)