On Wed, 2013-01-09 at 14:46 +0100, Christian Lamparter wrote: > > > [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?. Oops, no. I'm confusing HT action frames and BA agreement frames. Maybe the Nexus4 developers made the same mistake? :) > > 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. Yeah. But I think we're concerned about RX sessions here, so this behaviour isn't really all that relevant. Sorry, I'm still a bit confused I guess. Why do we even tear down RX sessions at all? > 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...]. Oh, right, ok. I tend to think that if a unicast management packet really didn't go through there isn't much you can do. Typically it would have been retried like a dozen times already ... 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
