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

On Monday 11 December 2006 20:07, Daniel Drake wrote:
> 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?
>
All 802.11 devices have to be able to handle retries in hardware to do random 
backoff properly. Still, the stack wants to know what happened.

> 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.
>
Yes, but it also uses successful transmissions in rate adjustment.

I don't think this race is such a big deal. It will only happen when someone 
is really trying to mess with the link, and would cause the rate control to 
jump to the highest speed. However, if someone is really trying to mess with 
the link this way, the stability of the link is in trouble anyways. Wait for 
stations to send frames, and send an ack for every unicast frame - everyone 
will get confused. To actually mess with this code, the attacker would have 
to transmit acks nearly continuously as it can't tell exactly when is a good 
time to screw things up, and the driver recovers as soon as the queue is 
emptied. Someone transmitting all the time is a problem for all wireless 
cards. :)

-Michael Wu

Content of type "application/pgp-signature" skipped