On 06/14/2017 11:18 PM, Emmanuel Grumbach wrote:
ath10k is a bit weird about flushing frames, and at least my variant of the wave-2
firmware does not always put the deauth frame on the air when deleting stations.
It will likely not be much fun to fix this. I was wondering if the code below
from ieee80211_set_disassoc() could (easily?) be made to wait for a tx-status of the deauth frame
instead of trying to force a flush?
That's exactly what it does:
Well, the end effect is supposed to be the same, at least...
/*
* drop any frame before deauth/disassoc, this can be data or
* management frame. Since we are disconnecting, we should not
* insist sending these frames which can take time and delay
* the disconnection and possible the roaming.
*/
if (tx)
ieee80211_flush_queues(local, sdata, true);
Remove all the pending data frames from the queues to clear the way
for the deauth.
Note the drop=true
/* deauthenticate/disassociate now */
if (tx || frame_buf)
ieee80211_send_deauth_disassoc(sdata, ifmgd->bssid, stype,
reason, tx, frame_buf);
Send the deauth.
/* flush out frame - make sure the deauth was actually sent */
if (tx)
ieee80211_flush_queues(local, sdata, false);
Wait for the deauth (drop=false).
The question here is how ath10k implements the flush(, drop=false)
Not well, it seems. I don't think it has a good way to flush (drop=false)
an individual vdev, though probably I could implement it. And, I think that
the packets in the mac80211 txqs might be difficult to flush.
But, mac80211 gets a txstatus when the deauth is sent, so if it simply
waited on that, it would not matter how flush is implemented. And, it might
try to re-send a time or two if getting the deauth through was worth the
wait and the initial attempt(s) got a false txstatus.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
