On Fri, 2015-07-17 at 11:05 +0200, Johannes Berg wrote: > 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? > Never mind, I was looking at the wrong code. I'll apply this. 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