linux-kernel - Re: [ath5k-devel] Unusually low speeds with ath5k and iwl3945

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 25 Nov 2008 23:47:38 +0100
From:	Felix Fietkau <nbd@...nwrt.org>
To:	Benoit PAPILLAULT <benoit.papillault@...e.fr>
CC:	Maxim Levitsky <maximlevitsky@...il.com>,
	Derek Smithies <derek@...ranet.co.nz>,
	ath5k-devel@...ts.ath5k.org, linux-wireless@...r.kernel.org,
	linux-kernel@...r.kernel.org, ipw3945-devel@...ts.sourceforge.net,
	wally@...blackmoor.net, Johannes Berg <johannes@...solutions.net>
Subject: Re: [ath5k-devel] Unusually low speeds with ath5k and iwl3945

Benoit PAPILLAULT wrote:
> Felix Fietkau a écrit :
>> While reading the code for calculating the frame duration, i noticed
>> something odd: It doesn't seem to be taking into account the short
>> vs long preamble distinction for ERP rates. IMHO this might be causing
>> issues like this. I've seen similar behaviour a long time ago when testing
>> iwl3945 against a Broadcom AP with exactly the same throughput drop (500-
>> 600 kbits/s).
>> When I analyzed the problem with an extra monitor mode card, I found out
>> that the throughput drop is caused by a huge number of retransmissions,
> 
> In the test I've done, there was no retransmission at all (no
> duplicates). I don't save a capture file, so I cannot tell for sure.
Which test specifically? iwl3945 or ath5k?
If ath5k doesn't show any retransmissions, the problem might not be
related. Please do make some logs of the throughput issue and then
some more of the same kind of traffic without throughput issues
(same card, same driver).

> What is the code computing frame duration you are referring to? How it
> could affect the hardware behavior?
I looked at it again and now I don't think it's the cause anymore. I
 did some comparisons against other stacks/drivers and this part
seems correct after all.

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