wpa_supplicant (Was: Re: wpi not working on today's current
bf1783 at googlemail.com
Sat May 29 10:54:02 UTC 2010
On 5/29/10, Rui Paulo <rpaulo at freebsd.org> wrote:
> On 29 May 2010, at 05:39, b. f. wrote:
>> On 5/28/10, Doug Barton <dougb at freebsd.org> wrote:
>>> On 5/28/2010 4:50 PM, b. f. wrote:
>>>> I can't see any problems when using WPA2 with AES on r208606 i386 with
>>>> uath(4). I'm updating this machine to r208630 tonight, and if I
>>>> encounter problems with the later revision, I'll let you know.
>>> Ok, thanks.
>>>> you saying that you experienced problems when trying to use a r207134
>>>> base with a r208626 kernel? If that's the case, I would recommend
>>>> updating the base to the same revision as the kernel, and then
>>> Yes, that's what I'm doing I actually tried running the newly built
>>> wpa_supplicant but that didn't work. I'm kind of hesitant to do the full
>>> upgrade since I'm having kernel problems with the nvidia driver, but if
>>> I'm sure wpa_supplicant will work then I suppose I can bite the bullet.
>> It appears that something is wrong. My wireless stick no longer
>> associates with the network with r208630. I'll do some tinkering.
> That's odd. The only way for that to happen would be caused bug in the
> taskqueue stuff that zml committed, I think, but that's a long shot.
> Rui Paulo
Yes, that was also my suspicion, and after seeing, via top(1), that
ifconfig is stuck in the "*taskq" state while attempting to set up
the wlan, I believe either r208623, or r208624, or both, is
responsible for the regression.
More information about the freebsd-current