Re: libdnet problem with monitor mode interfaces

[Djalal Harouni <tixxdz () opendz org>]

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 ?


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.

To test it, just create the monitor interface like this
(it should work with phy0 and adjust mon1):
# iw phy phy0 interface add mon1 type monitor


> addr_ston converts a struct sockaddr to libdnet's own struct addr.
> addr_ntos goes the other direction. I remember them as "sockaddr to
> numeric" and "numeric to sockaddr."
Thanks for the clarification.

-- 
tixxdz
http://opendz.org

Attachment: nmap_libdnet_ARPHRD_IEEE80211_RADIOTAP.patch
Description:

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