hi johannes,
sorry for the delayed response. i was off from work for a few days.
is'nt the station's capability and the AP capability intersected during
association? i always thought that the comment was mis-represented.
i did a small test and i see that the stations capability is actually
the subset of AP capabilities that both support.
if that is the case, then we do not have to check for the capability
independently there! do i miss something in my understanding?
also, if what i have stated above is correct, then yes, i feel delayed
block ack as a feature might need to be implemented on mac80211 and then
check for the same.
thanks and regards
Vivek
On Thu, 13 Dec 2012 15:01:59 +0100, Johannes Berg wrote:
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
