From owner-freebsd-current@FreeBSD.ORG Mon May 25 15:32:14 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 0FDFB106566B for ; Mon, 25 May 2009 15:32:14 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-fx0-f168.google.com (mail-fx0-f168.google.com [209.85.220.168]) by mx1.freebsd.org (Postfix) with ESMTP id 91DA48FC1E for ; Mon, 25 May 2009 15:32:13 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by fxm12 with SMTP id 12so3304922fxm.43 for ; Mon, 25 May 2009 08:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qIFXMkLZE6NtaXc7W25Kl0KeOtfumBXuW/is2MjPduo=; b=TfpIibw1ojnn3mAad/G2oCuWVDuY3/9CWuWEeIVy0clSVXuvU8ooAdUbjhnvRpkQDX jmjtE5Y0dlI+YtY2PE6rGWXXKYu2KcJA9gaC7VVxG/xY6Kk/WCOTd5ldhM4xGqHnzGvg efXLdIKplR4KJn95cq2AIlW320qcQyu7dr5t0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Q8Mv0EX0Vwo8UYpy465/8mT8C5KTMCPfq+dcjtU38iiHhrKbKEvILRrQpzh4bu13EQ 1YZ9Nn6JwIZGMNzA462Hf4RieFeY1t8ier48nb0dlRF+Q66FT5Ko13YHTA5uZf+6lbyF 9CD5M/tiFcsOyKbJkBDN65J0dwmoAr4s4x+Vk= MIME-Version: 1.0 Received: by 10.204.118.207 with SMTP id w15mr7053645bkq.126.1243265531995; Mon, 25 May 2009 08:32:11 -0700 (PDT) In-Reply-To: <3a142e750905250515i5e6a21b0qe6eee63973efa7b8@mail.gmail.com> References: <4A11A08B.6090309@errno.com> <3a142e750905250515i5e6a21b0qe6eee63973efa7b8@mail.gmail.com> Date: Mon, 25 May 2009 17:32:11 +0200 Message-ID: <3a142e750905250832p2af35f4fi3d70b26018c61faf@mail.gmail.com> From: "Paul B. Mahol" To: Sam Leffler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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:32:14 -0000 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. -- Paul