On Wednesday, January 09, 2013 01:02:45 PM Johannes Berg wrote: > On Wed, 2013-01-09 at 00:38 +0100, Christian Lamparter wrote: > > > So, my question now is: Does this reasoning make sense, or have I > > > missed anything? > > > > I think reordering 5 and 6 won't stop the race entirely. ACKs are > > usually generated by hardware (or firmware) right away when the received > > frame passed the CRC checks and found a place to stay in the HW's FIFOs. > > However by the time DELBA is processed by the peers' 802.11 stack, some > > frames on the tx-path might have left the DELBA in the dust [keep-alives > > and friends]. > > > > [Note: Action frames like DELBA have to be encrypted/decrypted when > > MFP/802.11w is enabled on the link and some HW/FW can't do that. So > > it takes even longer to react to those.] > > Actually no: HT action frames aren't robust management frames. DelBA is part of the Block Ack Actions as defined in 802.11-2012 8.5.5. The Block Ack category is marked in Table 8-38 as "robust"?! Was this changed from the original 11w spec? Maybe that would explain why the Nexus 4 thinks it doesn't need to de-/encrypt BA agreements?. > FWIW, our (Intel's) firmware will send frames from the aggregation > queues unaggregated as soon as it receives a DelBA frame from the > peer, so as long as it receives it there's no issue. Good. Then it was probably just more convenient ;). But we still need a case for HW which doesn't support IEEE80211_HW_REPORTS_TX_ACK_STATUS. > > [Note3: What will happen to DELBAs if they aren't acked? Is there a timeout > > or are they retried until the peer is dropped by other means? > > I'm asking this because with some hardware we have to be greedy with the > > number of open BA Agreements. For example ti's wl12xx can only support a > > limited number of open RX BA Agreements.] > > DelBA frames are unicast frames, so they're retried normally. Uh, this note was out of context. It had to do with a sentence from a previous post that wasn't discussed: On Tuesday, January 08, 2013 11:39:10 AM Johan Danielsson wrote: > It seems more reasonable to send the DELBA and wait for an ACK > before removing the BACK state (with ampdu_action). Currently this > is done the other way around. If we only call ampdu_action(RX_STOP) as part of a callback when we have received an ACK from a outgoing DELBA [yes I know some HW doesn't support that] what happens to BA agreements after all DELBAs retries have been used up? Or do we have to retry them endlessly? [I'm asking this because we do have a retry-when-we-receive-unicast for BARs already...]. Regards, Chr -- 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
