linux-kernel - Re: ath5k regression associating with APs in 2.6.38

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]

Date:	Tue, 17 May 2011 11:57:20 -0500
From:	Seth Forshee <seth.forshee@...onical.com>
To:	Nick Kossifidis <mickflemm@...il.com>
Cc:	"John W. Linville" <linville@...driver.com>,
	Jiri Slaby <jirislaby@...il.com>,
	"Luis R. Rodriguez" <lrodriguez@...eros.com>,
	Bob Copeland <me@...copeland.com>,
	linux-wireless@...r.kernel.org, ath5k-devel@...ema.h4ckr.net,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: ath5k regression associating with APs in 2.6.38

On Mon, May 09, 2011 at 09:02:30AM +0200, Seth Forshee wrote:
> On Thu, May 05, 2011 at 05:30:42PM +0300, Nick Kossifidis wrote:
> > Hmm I don't see any errors from reset/phy code, can you disable
> > Network Manager/wpa-supplicant and test connection on an open network
> > using iw ? It 'll give us a better picture...
> > 
> > If iw doesn't return any scan results we are probably hitting a PHY/RF
> > error specific to your device (not all vendors follow the reference
> > design). Maybe we should follow a blacklist/whitelist approach for
> > this feature.
> 
> I got the results back from my tester. He was able to get scan results,
> but it took multiple tries and the direct probe failures appear in the
> log. He didn't enable ATH5K_DEBUG_RESET this time; let me know if you
> need that and I'll request he retest with the extra debug logs enabled.

I got some more feedback. Most of the time iw does not get scan results,
but even when it does connecting to the AP isn't always successful. The
tester did note that he doesn't seem to have any trouble if his machine
is within a few feet of his AP. Let me know if you'd like something else
tested.

I noticed that bugzilla #31922 (ath5k: Decreased throughput in IBSS or
802.11n mode) is also fixed by reverting 8aec7af9. It seems like the
synth-only channel changes are resulting in poor connection quality.
Maybe that patch needs to be reverted?

Thanks,
Seth

--
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/