Re: libdnet problem with monitor mode interfaces

[David Fifield <david () bamsoftware com>]

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

> 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):
> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2011-February/004144.html
>
> 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.

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