linux-kernel - Re: [.32-rc1/2] ath5k: has become unreliable with .32-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090930122451.GA17280@hash.localnet>
Date:	Wed, 30 Sep 2009 08:24:51 -0400
From:	Bob Copeland <me@...copeland.com>
To:	Frans Pop <elendil@...net.nl>
Cc:	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [.32-rc1/2] ath5k: has become unreliable with .32-rc1

On Wed, Sep 30, 2009 at 09:52:27AM +0200, Frans Pop wrote:
> This is on a laptop I don't use much, but with .31 wireless has always
> been (and still is) reliable (.31-rc5 is the last kernel I built for it).
> On my other laptop wireless (iwlagn) works fine with .32-rc1.

Although iwlagn works, I would think this kind of thing:

> ath0: authenticated
> ath0: associate with AP 00:14:c1:38:e5:15 (try 1)
> ath0: RX ReassocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=2)
> ath0: associated
> ath0: deauthenticating by local choice (reason=3)
> ath0: direct probe to AP 00:14:c1:38:e5:15 (try 1)
> ath0 direct probe responded
> ath0: authenticate with AP 00:14:c1:38:e5:15 (try 1)
> ath0: authenticated
> ath0: associate with AP 00:14:c1:38:e5:15 (try 1)
> ath0: RX ReassocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=2)

...is some kind of issue with userspace or wext rather than the driver.
Ath5k only had a dozen or so patches this time around, so it should be
easy to bisect if it's a problem in the driver.  One possibility is
hardware CCMP support but I've been using it here for some time.

By the way, name it what you will, but the standard is wlan0 these days :)

> So the difference looks to be how I boot: if I do a *cold* boot directly
> into .32, wireless fails; if I *reboot* from .31 into .32, wireless
> comes up correctly. Reboot from .32 to .32 fails too.

Is that repeatable?

Rafael J. Wysocki has a patch floating around to fix PCMCIA resume,
linked here: http://bugzilla.kernel.org/show_bug.cgi?id=13092

-- 
Bob Copeland %% www.bobcopeland.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/