From owner-freebsd-mobile@FreeBSD.ORG Thu Mar 27 05:54:00 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 0F4DA106564A; Thu, 27 Mar 2008 05:54:00 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id C87118FC17; Thu, 27 Mar 2008 05:53:59 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from Macintosh-2.local ([10.0.0.196]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m2R5rjXQ064087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 22:53:52 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <47EB3669.8090909@freebsd.org> Date: Wed, 26 Mar 2008 22:53:45 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Sepherosa Ziehau References: <20080326124324.GA1756@rebelion.Sisis.de> <47EA53D5.4070106@student.utwente.nl> <47EA73D9.6050302@freebsd.org> <47EA8949.9070700@student.utwente.nl> <47EA8E43.1080308@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-URT-Metrics: ebb.errno.com; whitelist 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 05:54:00 -0000 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 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 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