Michael Wu wrote:
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. :)
It's ugly, in my mind not necessary, and it will kill performance. We haven't had to make such compromises in a long time. We got a large TX speed boost when the driver was modified to queue up multiple transmit URBs (i.e. don't wait for URB completion of the first) at the same time early during driver development. And even with that we're still a fair distance from the performance of the vendor driver.
While the stack isn't so well suited for this device I'd much prefer to see a more simplistic workaround. For example, assume all packets were successful but then report a failure when an interrupt comes in. Or, if the stack won't accept out-of-the-blue notifications like that, then maintain a counter which is incremented when a failure is reported, and when transmitting the next few frames report them as failed and decrement the counter (while counter > 0). Maybe disable rate control until we can come up with a nicer solution.
Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
