Re: [PATCH] mac80211: reset addba retries after timeout

[Johannes Berg <johannes@sipsolutions.net>]

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