Hi Vivek,
> if you are referring to the addba-request to transmit a ADDBA with
> delayed block ack, yes, i accept what you have stated. but, then we
> would need to support delayed block ack on the TX.
>
> for my query, i was thinking more with respect to the receive side of
> an AP.
Ah, ok.
> if, let us say a particular station is capable of delayed block ack
> which might not be a linux station(presently it seems, linux box will
> only pursue immediate block ack), then on receive of a block ack
> request, the lower layer can just send an ack if the policy is known to
> be delayed block ack.
Right now, a mac80211-based station should probably never even advertise
that it is delayed-BA capable since it won't correctly be handled.
Therefore, any other station must not ask for a delayed-BA session in
its AddBA request. And in fact, ieee80211_process_addba_request() drops
frames that ask for delayed BA.
So I guess what you're really saying is that you want to implement
delayed BA and address the todo item in
ieee80211_process_addba_request() that says:
/* XXX: check own ht delayed BA capability?? */
i.e. add a check here for our own capability and add a new parameter to
let the driver know...
Overall that seems reasonable.
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
