Date: Wed, 3 Nov 2010 08:27:02 +0100 From: Bernhard Schmidt <bschmidt@freebsd.org> To: David Wolfskill <david@catwhisker.org> Cc: current@freebsd.org Subject: Re: wpa_supplicant gets points for trying, I suppose.... Message-ID: <201011030827.02253.bschmidt@freebsd.org> In-Reply-To: <20101102215518.GA1980@albert.catwhisker.org> References: <20101101222510.GY1506@albert.catwhisker.org> <AANLkTik=fSknU6LfmAdbh1Lk-idEU7BwKaPmi1qCxnk3@mail.gmail.com> <20101102215518.GA1980@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, November 02, 2010 22:55:18 David Wolfskill wrote: > On Tue, Nov 02, 2010 at 06:30:10PM +0100, Bernhard Schmidt wrote: > > .... > > Thanks. I had quick look into that and I currently do not see an easy > > way to address that issue, as in tell wpa_supplicant about the device's > > state. This might change though once a newer wpa_supplicant has been > > imported. > > I'm not entirely surprised -- a quick look I took at sys/dev/iwn seemed > to indicate to me that whiule iwn(4) could whine about the switch, it > didn't have much in the way of ability to actually provide information > about that status in some other way (e.g., a non-zero return from > attempt to mess with the device). But I don't claim extensive expertise > in that area. There is ieee80211_notify_radio(), granted iwn(4) misses the calls.. that function is supposed to notify upper layers about the radio state (0 = off, 1 = on). Anyways, once wpa_supplicant import/update is done, I'll probably have a look into that again. > > For now just add wpa_supplicant_flags="-qqqq" to rc.conf. > : > :-} That, or decide to ignore the silly messages.... Noted, thanks. > > Peace, > david -- Bernhard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201011030827.02253.bschmidt>