On Thu, 2015-07-02 at 09:59 +0200, Michal Kazior wrote: > When acting as AP and a PS-Poll frame is received > associated station is marked as one in a Service > Period. This state is kept until Tx status for > released frame is reported. While a station is in > Service Period PS-Poll frames are ignored. > > However if PS-Poll was received during A-MPDU > teardown it was possible to have the to-be > released frame re-queued back to pending queue. > In such case the frame was stripped of 2 important > flags: > > (a) IEEE80211_TX_CTL_NO_PS_BUFFER > (b) IEEE80211_TX_STATUS_EOSP > > Stripping of (a) led to the frame that was to be > released to be queued back to ps_tx_buf queue. If > station remained to use only PS-Poll frames the > re-queued frame (and new ones) was never actually > transmitted because mac80211 would ignore > subsequent PS-Poll frames due to station being in > Service Period. There was nothing left to clear > the Service Period bit (no xmit -> no tx status -> > no SP end), i.e. the AP would have the station > stuck in Service Period. Beacon TIM would > repeatedly prompt station to poll for frames but > it would get none. > > Once (a) is not stripped (b) becomes important > because it's the main condition to clear the > Service Period bit of the station when Tx status > for the released frame is reported back. > > This problem was observed with ath9k acting as P2P > GO in some testing scenarios but isn't limited to > it. AP operation with mac80211 based Tx A-MPDU > control combined with clients using PS-Poll frames > is subject to this race. I'm not sure I quite understand - how is the aggregation teardown causing frame filtering? johannes -- 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
