[I've added the zd1211rw maintainers to the CC, I hope they can shed some light on the question whether the ack queue mechanism that driver has is actually correct] I've had a closer look at the idea of deciding whether a frame has been transmitted succesfully by monitoring incoming ACK frames and I've hit a fundamental problem: How do you correlate incoming ACK frames to the frames that were actually transmitted? The ACK frame only carries the address of the station that transmitted the frame being acked, no further information. Now this means if you have the hardware TX two frames and receive one ACK frame in the RX path, you cannot know which TX frame the ACK belongs to, because they will be identical, right? The hardware, however, knows, because the ACKs are required to be transmitted directly after the corresponding frame is received, but we don't know in the driver about this timing information, at least not for rt2x00. I wonder whether the ack queue idea Mikko found in the zd1211rw driver is actually working correctly for that driver? I've only had a short look, but found that incoming ACKs are only matched against transmitted frames by means of the address carried within the ACK. So I'd think in the situation I outlined above, the zd1211rw driver will also be unable to match the ACK to the correct frame. Any comments on this? Mattiass -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
