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
pgpqy0LQcl1DB.pgp
Description: PGP signature
