Christian Lamparter wrote:
> But what seems to be strange is the tx feedback...
> Because it looks like ath9k_htc just sets IEEE80211_TX_STAT_ACK
> for every frame, which obviously can't be "true", right? ;)
>
> This might also break mac80211's *unicast buffering*.
>
> Because the code in ieee80211_tx_status - net/mac80211/status.c
> works like this:
>
> 211 acked = !!(info->flags & IEEE80211_TX_STAT_ACK);
> 212 if (!acked && test_sta_flags(sta, WLAN_STA_PS_STA)) {
> 213 /*
> 214 * The STA is in power save mode, so assume
> 215 * that this TX packet failed because of that.
> 216 */
> 217 ieee80211_handle_filtered_frame(local, sta, skb);
> 218 rcu_read_unlock();
> 219 return;
> 220 }
> ...
> 239 if (info->flags & IEEE80211_TX_STAT_TX_FILTERED) {
> 240 ieee80211_handle_filtered_frame(local, sta, skb);
> 241 rcu_read_unlock();
> 242 return;
> 243 } else {
> 244 if (!acked)
> 245 sta->tx_retry_failed++;
> 246 sta->tx_retry_count += retry_count;
> 247 }
>
> so, mac80211 will never know when it needs to resend certain
> frame which could be affected by the race between the "sleepy"
> station sending a frame with a PSM-bit set and mac80211 finally
> updating the WLAN_STA_PS_STA flag.
> [see long comment in mac80211/status.c @ line 73]
What about hardware that doesn't report any kind of TX status information at
all ?
Currently, there is no way to determine whether the frame has actually gone out,
all that can be known is that it was pushed to the target.
> unless of course, you don't need it and the firmware can
> buffer those frames until the STA comes back?!
Hm, unfortunately the firmware has no such feature currently.
Sujith
_______________________________________________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
