802.11 monitor mode changes coming
Sam Leffler
sam at errno.com
Mon May 25 15:49:04 UTC 2009
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
>> @@ -102,6 +102,8 @@
>> 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
-------------- next part --------------
Index: ieee80211_radiotap.c
===================================================================
--- ieee80211_radiotap.c (revision 192470)
+++ ieee80211_radiotap.c (working copy)
@@ -102,12 +102,12 @@
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
More information about the freebsd-current
mailing list