Re: 802.11 monitor mode changes coming

Paul B. Mahol wrote:
> On 5/25/09, Paul B. Mahol <onemda_at_gmail.com> wrote:
>   
>> On 5/18/09, Sam Leffler <sam_at_errno.com> wrote:
>>     
>>> The patch here:
>>>
>>> http://people.freebsd.org/~sam/monitor-20090518.patch
>>>
>>> has significant changes to monitor mode operation.  Most importantly it
>>> replaces DLT_IEEE802_11 support in net80211 by DLT_IEEE802_11_RADIO and
>>> removes the latter from the underlying device.  The upshot is that you
>>> can no longer do:
>>>
>>> tcpdump -i ath0
>>>
>>> instead you will now need a wlanX ifnet; e.g.
>>>
>>> ifconfig wlan create wlandev ath0 wlanmode monitor channel 6 up
>>> tcpdump -i wlan0 -y IEEE802_11_RADIO
>>>
>>> This addresses the longstanding issue that applications like kismet that
>>> want radiotap data needed to open two ifnets, one to receive data and
>>> one to do channel changes.  My main concern is whether losing
>>> DLT_IEEE802_11 support will affect any apps.  Those that depend on it
>>> should be easy to change; you just request a different DLT and strip the
>>> radiotap header from tap'd frames (or similar).
>>>
>>> In sweeping the drivers to do these changes I've made radiotap support
>>> more consistent and improved some drivers.  Drivers not tested so far:
>>> malo, ipw, wpi, and upgt.  I tested iwi and it appears broken in that no
>>> frames are rx'd but I'm not sure I'll look at it before 8.0.
>>>
>>> I plan to commit these changes by the end of the week.
>>>       
>> It makes ndisulator panic, following stupid patch fix it for me:
>>
>> --- /sys/net80211/ieee80211_radiotap.c  2009-05-25 12:14:29.000000000 +0000
>> +++ ieee80211_radiotap.c        2009-05-25 12:13:59.000000000 +0000
>> _at__at_ -102,6 +102,8 _at__at_
>>         struct ieee80211com *ic = vap->iv_ic;
>>         struct ieee80211_radiotap_header *th = ic->ic_th;
>>
>> +       if (th == NULL)
>> +               return;
>>         KASSERT(th != NULL, ("no radiotap setup"));
>>
>>         /* radiotap DLT for raw 802.11 frames */
>>     
>
> Unfortunately this one makes system panic on detach somewhere in bpf code,
> so correct way to fix this is to use radiotap code only and only if device
> have monitor cap.
>
>   

You haven't provided any information about what you're doing or what  
the crash looks like.  If the radiotap DLT is never setup then I would 
expect detach to never touch it.  The attached patch should hopefully do 
that; you need to verify both tx+rx header state are present as there 
are paths through the code that use each and checking only tx in 
ieee80211_radiotap_vattach is insufficient (right now at least).

    Sam



Index: ieee80211_radiotap.c
===================================================================
--- ieee80211_radiotap.c	(revision 192470)
+++ ieee80211_radiotap.c	(working copy)
_at__at_ -102,12 +102,12 _at__at_
 	struct ieee80211com *ic = vap->iv_ic;
 	struct ieee80211_radiotap_header *th = ic->ic_th;
 
-	KASSERT(th != NULL, ("no radiotap setup"));
-
-	/* radiotap DLT for raw 802.11 frames */
-	bpfattach2(vap->iv_ifp, DLT_IEEE802_11_RADIO,
-	    sizeof(struct ieee80211_frame) + le16toh(th->it_len),
-	    &vap->iv_rawbpf);
+	if (th != NULL && ic->ic_rh != NULL) {
+		/* radiotap DLT for raw 802.11 frames */
+		bpfattach2(vap->iv_ifp, DLT_IEEE802_11_RADIO,
+		    sizeof(struct ieee80211_frame) + le16toh(th->it_len),
+		    &vap->iv_rawbpf);
+	}
 }
 
 void