On Tue, 2011-11-29 at 17:01 -0500, Nikolay Martynov wrote: > >> Do APs broken is such way exist? I.e. APs which declare aggregation > >> support but do not respond to addba. > > > > I seem to remember something ... not really sure. > > If such APs exist I think it might be possible to extend my patch to > do something like the following. For the first time make 10 attempts > to establish addba. If this fails - make no more attempts for the > duration of the connection. If this succeeds - use logic I've added in > the patch. This should handle broken APs and won't allow agg to be > disable because of some random blackout. Wouldn't that be equivalent to just bumping the number of tries? > >> On the other hand looking at the code I've got an impression that > >> connection doesn't stall while waiting for addba resp, i.e. packets > >> still go though non-agg path. Did I miss something in this regards? > > > > We queue up packets in ieee80211_tx_prep_agg() when > > HT_AGG_STATE_WANT_START is clear but HT_AGG_STATE_OPERATIONAL is not > > set, this is the case after we send the addBA request frame and before > > we get a response. So since the timeout is 1 second, the connection can > > stall for quite a while. > > Is the any particular reason why packets are not being sent via > non-agg path while agg path is being established? I'm not suggesting > that it is wrong, I'm just curious. The delay in data transmission > you've mentioned in regards to my patch is probably applicable here > too, so won't it make sense to ignore agg until it is fully set up? It's required because you tell the peer what the first aggregated packet's sequence number is going to be. 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
