mailing list archives
Re: libdnet problem with monitor mode interfaces
From: David Fifield <david () bamsoftware com>
Date: Tue, 29 May 2012 13:48:32 -0700
On Tue, May 29, 2012 at 06:11:59PM +0100, Djalal Harouni wrote:
On Tue, May 29, 2012 at 08:10:58AM -0700, David Fifield wrote:
Wouldn't it be better to add this support to addr_ston? There is already
the same memcpy in addr_ston, but only for the types AF_UNSPEC and
ARP_HRD_ETH. Does adding ARPHRD_IEEE80211_RADIOTAP in addr_ston solve
the problem too?
Yes, defining the ARPHRD_IEEE80211_RADIOTAP solves this case, but what
if another use reports the same problem but with a different ARPHDR_* value ?
I think that's fine. We can handle these case-by-case as they come up.
Potentially for a new header format we have to do something different; I
don't think it's correct to use the same memcpy for all unknown header
If we want to go this way then it seems that we can rely on
ARPHRD_IEEE80211_RADIOTAP, since it's also used outside the kernel, the
madwifi driver and the batctl (B.A.T.M.A.N. control tool):
Linux Ref: http://lxr.free-electrons.com/ident?i=ARPHRD_IEEE80211_RADIOTAP
Patch is attached, the --iflist will show the monitor interface and
hopefully Nmap will peekup the right one.
I think this is fine. But let's use the name ARP_HRD_IEEE80211_RADIOTAP
(extra underscore) because that matches the other internal libdnet
definitions. Please commit it.
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)