From owner-freebsd-mobile@FreeBSD.ORG Thu Mar 27 06:33:01 2008 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F17B4106568C for ; Thu, 27 Mar 2008 06:33:00 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id A64E38FC1D for ; Thu, 27 Mar 2008 06:33:00 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so94290anc.13 for ; Wed, 26 Mar 2008 23:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=VZa9Kc5BOnPEAbauKWS8AW7Jut+pOgD5STe1FkoTdHI=; b=c+UZaMW25QinH9vA7B1HHXYwkuaPVcDfgnhlj9LKubY7iQ8BifNMNdgdQj1Pg9EqbziTqSN9etvyWWbw2QbkDuGZpKsGS51833YUs82s80r6HbkoIatp2M3Ot3kf34GyxcQ8zj4KTobTyWGrIU/Lj/t+nW7GjEmPp7qdvPXr7/A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=upN7aw9ghbPk9ueV+j4OrOOP6Fyu/XGrzlLIbIyR2V+dcNb4PYBKmZV4NMTsWQ4L/UwM/if1sbTQEElOGm2O8A63dXsDhw7DkRwHH+qB96AJjjL+loCNyc7s5t368jXWmWHxwntNHc0SkozNDKeEsnqMYtBHn/bNOWwIoOMbm2M= Received: by 10.100.249.9 with SMTP id w9mr2366143anh.63.1206599579819; Wed, 26 Mar 2008 23:32:59 -0700 (PDT) Received: by 10.100.8.19 with HTTP; Wed, 26 Mar 2008 23:32:59 -0700 (PDT) Message-ID: Date: Thu, 27 Mar 2008 14:32:59 +0800 From: "Sepherosa Ziehau" To: "Sam Leffler" In-Reply-To: <47EB3669.8090909@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080326124324.GA1756@rebelion.Sisis.de> <47EA53D5.4070106@student.utwente.nl> <47EA73D9.6050302@freebsd.org> <47EA8949.9070700@student.utwente.nl> <47EA8E43.1080308@freebsd.org> <47EB3669.8090909@freebsd.org> Cc: Matthias Apitz , Andrew Thompson , Alphons Fonz van Werven , freebsd-mobile@freebsd.org Subject: Re: 7.0-RELEASE && panic after ~4 hours X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2008 06:33:01 -0000 On Thu, Mar 27, 2008 at 1:53 PM, Sam Leffler wrote: > > Sepherosa Ziehau wrote: > > On Thu, Mar 27, 2008 at 1:56 AM, Sam Leffler wrote: > >> Alphons "Fonz" van Werven wrote: > >> > >>> Sam Leffler wrote: > >> > > >> >> I am aware only of issues with USB adapters being removed while > >> >> wpa_supplicant is running. > >> > > >> > Actually, there's more I'm afraid. > >> > > >> > iwi: Don't know because I don't use that one. But it's a "cousin" of > >> > wpi and > >> > if I'm not mistaken it was the same person who initiated > >> > development of > >> > both drivers. > >> > > >> > wpi: No panics, but just doesn't work with wpa_supplicant at all > >> > (fails to > >> > associate). This is a known problem and people are working on it. > >> > >> You said there were panics; please point me at PR's that show them or > >> stop saying it. Also these drivers are completely different and linking > >> them is uninformed. > >> > >> The problem with almost all the reports I've seen is they lack > >> sufficient info to even respond. Understand that most all Intel > >> wireless cards up to the 4965 have issues with firmware mis-design that > >> make developing reliable drivers hard (even more so given Intel's > >> unwillingness in helping anyone not using linux). For example the > >> ipw+iwi drivers try to work around the fact there is no way to scan w/o > > > > I can't comment on iwi. For ipw+1.3firmare and in STA mode, clearing > > BSSID before starting the firmware can prevent firmware from > > auth/assoc. However, the scan channel mask in STA mode is completely > > ignored by firmware, but in IBSS mode, the scan channel mask is > > obeyed. In dfly, I did following stuffs in the new driver (ipw was > > dumped): > > 1) before scanning (i.e. before starting the firmware; since once the > > firmware is started, it will start scanning; scan command is actually > > ignored), the BSSID is cleared > > 2) After 802.11 generic layer has picked up the BSS to join, reinit > > the firmware but this time set the BSSID of the selected BSS to > > firmware. > > That's basically how my rewrite of ipw deals with the issue(s). I > invalidate the state so the firmware cannot locate an ap to join. The > problem however is that the firmware will continue to scan until the > host resets state such that it can join. This "skid" leads to various > issues that are made worse by the scan abort command not working reliably. I stop the firmware completely if I want to make some configuration changes. Rest of the ways like what Intel's Linux driver does promise to give a firmware fatal error. My way obvious does not work with bgscan :( > > I just did a rewrite of wi that takes a different tack that might also > work for ipw. I set the card in monitor mode and scan using net80211 to I tried that way, when I wrote the new driver for ipw2100. It does not work on certain parts though: some parts can't hear packets or receive junked packets on channels above 11 when in monitor mode, but these parts work (e.g. scan) just fine in STA mode on channels above 11. Linux's intel driver uses different channel mask (different location in EEPROM) for IBSS and monitor mode, this channel mask contains less channels than the BSS channel mask. Though IBSS mode just works fine on all BSS channels listed in BSS channel mask, monitor mode only work on channels listed in the other channel mask. BTW, do you also imply that you inject scan probe packets in monitor mode ;)? Best Regards, sephe > handle the hard work. Once scan results are collected the driver then > brings the firmware up and instructs it to join a specific bssid on a > specific channel. I expect this will finally allow proper integration > with wpa_supplicant. > > Sam > > -- Live Free or Die