iwlwifi: mvm: don't let NDPs mess the packet tracking
We need to track the next packet that we will reclaim in order to know when the Tx queues are empty. This is useful when we open or tear down an A-MPDU session which requires to switch queue. The next packet being reclaimed is identified by its WiFi sequence number and this is relevant only when we use QoS. QoS NDPs do have a TID but have a meaningless sequence number. The spec mandates the receiver to ignore the sequence number in this case, allowing the transmitter to put any sequence number. Our implementation leaves it 0. When we reclaim a QoS NDP, we can't update the next_relcaim counter since the sequence number of the QoS NDP itself is invalid. We used to update the next_reclaim based on the sequence number of the QoS NDP which reset it to 1 (0 + 1) and because of this, we never knew when the queue got empty. This had to sad consequence to stuck the A-MPDU state machine in a transient state. To fix this, don't update next_reclaim when we reclaim a QoS NDP. Alesya saw this bug when testing u-APSD. Because the A-MPDU state machine was stuck in EMPTYING_DELBA, we updated mac80211 that we still have frames for that station when it got back to sleep. mac80211 then wrongly set the TIM bit in the beacon and requested to release non-existent frames from the A-MPDU queue. This led to a situation where the client was trying to poll frames but we had no frames to send. Reported-by: Alesya Shapira <alesya.shapira@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Showing
Please register or sign in to comment