From owner-freebsd-current@FreeBSD.ORG Mon May 25 15:49:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5C511065677 for ; Mon, 25 May 2009 15:49:03 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 926F98FC15 for ; Mon, 25 May 2009 15:49:03 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n4PFn2T4095427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 May 2009 08:49:02 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4A1ABDEE.3060503@errno.com> Date: Mon, 25 May 2009 08:49:02 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: "Paul B. Mahol" References: <4A11A08B.6090309@errno.com> <3a142e750905250515i5e6a21b0qe6eee63973efa7b8@mail.gmail.com> <3a142e750905250832p2af35f4fi3d70b26018c61faf@mail.gmail.com> In-Reply-To: <3a142e750905250832p2af35f4fi3d70b26018c61faf@mail.gmail.com> Content-Type: multipart/mixed; boundary="------------090008010204020400030203" X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: current@freebsd.org Subject: Re: 802.11 monitor mode changes coming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 15:49:04 -0000 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 wrote: > >> On 5/18/09, Sam Leffler 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--