Hi, I've just reviewed the beacon handling in rt2x00 in AP mode and experienced some inconsistencies. The DTIM count is not correctly updated: sometimes multiple beacons are sent out using the same DTIM count. rt2x00 calls ieee80211_beacon_get_tim right after the current beacon was sent out to fetch the next one. However, rt2x00 also implements the set_tim callback and updates the beacon in each call to set_tim. As far as I understood the code in mac80211 the set_tim callback is called when the first frame for a powersaving station gets queued. Since every call to ieee80211_beacon_get_tim updates the DTIM count the following can happen (assuming a DTIM period of 2): - the hw sends out the current beacon (DTIM count == 0) - call to ieee80211_beacon_get_tim fetches the next beacon (DTIM count == 1) - the first frame for a PS STA gets queued -> set_tim - again call ieee80211_beacon_get_tim (DTIM count == 0) - hw sends out the beacon with incorrect DTIM count A proper way of fixing this issue would be not to use the set_tim callback but just fetch the next beacon right before it gets send out (like ath* does). However, that's not easily possible with rt2x00 devices older then rt2800 as they only generate beacon_done interrupts (which is obviously too late for fetching the current beacon ;) ). So, is the current implementation in rt2x00 supposed to work and mac80211 needs fixing? Could we add a parameter to ieee80211_beacon_get_tim that indicates if a _new_ beacon should be generated or if the _current_ beacon should be updated in response to the set_tim callback? Any other ideas? Thanks, Helmut -- 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
