Date: Mon, 25 May 2009 08:49:02 -0700 From: Sam Leffler <sam@errno.com> To: "Paul B. Mahol" <onemda@gmail.com> Cc: current@freebsd.org Subject: Re: 802.11 monitor mode changes coming Message-ID: <4A1ABDEE.3060503@errno.com> In-Reply-To: <3a142e750905250832p2af35f4fi3d70b26018c61faf@mail.gmail.com> References: <4A11A08B.6090309@errno.com> <3a142e750905250515i5e6a21b0qe6eee63973efa7b8@mail.gmail.com> <3a142e750905250832p2af35f4fi3d70b26018c61faf@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------090008010204020400030203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Paul B. Mahol wrote: > On 5/25/09, Paul B. Mahol <onemda@gmail.com> wrote: > >> On 5/18/09, Sam Leffler <sam@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 --------------090008010204020400030203 Content-Type: text/plain; name="radiotap.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="radiotap.patch" 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 --------------090008010204020400030203--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A1ABDEE.3060503>