Hi, 2011/11/29 Johannes Berg <johannes@xxxxxxxxxxxxxxxx>: > Hi Nikolay, > >> > Conceptually, this seems OK to me, although on broken APs it might mean >> > connection stalls every minute, not sure how desirable that is? >> >> 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. > >> 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? Thanks! -- Truthfully yours, Martynov Nikolay. Email: mar.kolya@xxxxxxxxx -- 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
