From owner-freebsd-net@FreeBSD.ORG Sat Oct 9 18:49:31 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A5FE106566B; Sat, 9 Oct 2010 18:49:31 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7F3B18FC18; Sat, 9 Oct 2010 18:49:30 +0000 (UTC) Received: by fxm12 with SMTP id 12so136431fxm.13 for ; Sat, 09 Oct 2010 11:49:27 -0700 (PDT) Received: by 10.223.98.193 with SMTP id r1mr660428fan.144.1286650167641; Sat, 09 Oct 2010 11:49:27 -0700 (PDT) Received: from julie.lab.techwires.net ([178.2.204.101]) by mx.google.com with ESMTPS id m8sm2058268faj.11.2010.10.09.11.49.24 (version=SSLv3 cipher=RC4-MD5); Sat, 09 Oct 2010 11:49:25 -0700 (PDT) From: Bernhard Schmidt To: Alexey Dokuchaev Date: Sat, 9 Oct 2010 20:46:41 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.1; amd64; ; ) References: <4763016D.7060100@janh.de> <201010081944.50287.bschmidt@techwires.net> <20101009060239.GA88618@FreeBSD.org> In-Reply-To: <20101009060239.GA88618@FreeBSD.org> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_RiLsMwW/r8wTxKE" Message-Id: <201010092046.41551.bschmidt@techwires.net> Cc: Paul B Mahol , net@freebsd.org Subject: Re: Monitor mode not working for iwi(4) on 7.X X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 18:49:31 -0000 --Boundary-00=_RiLsMwW/r8wTxKE Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit On Saturday 09 October 2010 08:02:39 Alexey Dokuchaev wrote: > On Fri, Oct 08, 2010 at 07:44:50PM +0200, Bernhard Schmidt wrote: > > On Friday 08 October 2010 19:36:13 Bernhard Schmidt wrote: > > > After having another cup of coffee it's pretty obvious what's wrong. > > > The only difference between what I did and your scenario is, that I > > > didn't use > > > ifconfig iwi0 mediaopt monitor > > > but > > > ifconfig iwi0 monitor > > I haven't look in the source yet, but what is the difference between > "mediaopt monitor" and "monitor"? The first is SIOCSIFMEDIA the other SIOCGIFFLAGS. The later probably only worked by accident.. > > > instead.. anyways.. > > > > > > Attached patched should behave better now. > > > > Sorry.. correct one this time. > > Much better! "airodump-ng iwi0" now sees stations in addition to APs, > which means it can utilize monitor mode. "ifconfig iwi0 scan" however > does not work after that (and "list scan" returns no results) even if I > put adapter back to normal (from promisc and monitor modes) with > ifconfig(8). kldunloading and loading module again fixes the issue. Due to enqueueing the scan command in an infinite loop (yeah.. scanning returns every frame, that's monitor mode for that device.. *sigh*) we might increment a queue index but never actually dequeueing the command. On 'down' we clear the command queue but not the indicies resulting in the cur index not pointing to a filled entry. Attached patch should fix that. On a side note, you should never be required to run 'ifconfig dev scan', because after 'ifconfig dev up' the device is always in SCAN state (at least in station mode). Using 'ifconfig dev list scan' is sufficient enough. The 'scan' command is usally used to trigger a background scan while not being in SCAN state and those tend to get suspended pretty often (eg. when packets need to be sent), this is what you see as a hang. > Injection test "aireplay-ng -9 iwi0" still fails, but as I've been told > this is firmware issue (i.e. not possible with iwi(4)), which is also > inline with dmesg: > > kernel: iwi0: firmware error > kernel: iwi0: iwi_cmd: cmd 6 not sent, busy > kernel: iwi0: device configuration failed > > Googling shows that people patch Linux drivers to support injection, but > I do not know if any of that information is applicable to FreeBSD. It might be possible with lots of ugly hacks to get that device sending some kind of frames, 'injecting' those frames via net80211 shouldn't be that hard. At least the code is there according to comments in ieee80211_output.c. I do not consider this worth the effort though, if someone wants to work on that, let me know. > Apart from that, machine seems stable, and monitor mode is fixed. Thanks > a lot! You're welcome :) -- Bernhard --Boundary-00=_RiLsMwW/r8wTxKE Content-Type: text/x-patch; charset="ISO-8859-1"; name="iwi_fix_queue_idex.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="iwi_fix_queue_idex.diff" Index: sys/dev/iwi/if_iwi.c =================================================================== --- sys/dev/iwi/if_iwi.c (revision 213584) +++ sys/dev/iwi/if_iwi.c (working copy) @@ -3267,6 +3298,7 @@ iwi_stop(void *priv) ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); memset(sc->sc_cmd, 0, sizeof(sc->sc_cmd)); + sc->sc_cmd_cur = sc->sc_cmd_next = 0; sc->sc_tx_timer = 0; sc->sc_rfkill_timer = 0; sc->sc_state_timer = 0; --Boundary-00=_RiLsMwW/r8wTxKE--