netdev - Re: d80211-drivers pull request (week-48)

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:	Mon, 11 Dec 2006 20:07:32 -0500
From:	Daniel Drake <dsd@...too.org>
To:	Michael Wu <flamingice@...rmilk.net>
CC:	John Linville <linville@...driver.com>, netdev@...r.kernel.org,
	Ulrich Kunitz <kune@...ne-taler.de>
Subject: Re: d80211-drivers pull request (week-48)

Michael Wu wrote:
>       zd1211rw-d80211: Use ieee80211_tx_status

I've thought some more about this and I'm not so sure that this is the 
right approach.

Can't devicescape be taught that the ZD1211 handles retries in hardware 
and the stack doesn't need to worry about it?

What does devicescape do in response to not getting an ack? Does it 
retransmit? If that is all then it doesn't need to be at stack level, 
since the hardware handles that on its own, and we can configure that to 
behave the same way as the stack would.

I think I remember reading that devicescape uses failed transmission 
rate in the rate adjustment calculations. Even without this racy ack 
system we can still achieve that - the device tells us every time it 
retries a transmit, and then it sends a special interrupt at the end 
saying that all retries failed.

Daniel

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html