Re: [RFC PATCH] wifi: ath9k: clear destination mask for non-aggregate frames

[Tomas Tonhauser <t.tonhauser@pobox.sk>]

On Mon, Oct 19, 2026 at 10:33:33PM +0200, Toke Høiland-Jørgensen wrote:
> Tomas Tonhauser <t.tonhauser@pobox.sk> writes:
> 
> > Frames to stations without an A-MPDU session (e.g. non-WMM/non-HT
> > clients) use the non-aggregate path. If the hardware returns such a
> > frame with ATH9K_TXERR_FILT, ath_tx_complete_buf() reports it to
> > mac80211 as IEEE80211_TX_STAT_TX_FILTERED. For a station that is not
> > in powersave, ieee80211_handle_filtered_frame() retries it once and
> > drops it if it is filtered again.
> >
> > The aggregate path re-queues filtered subframes on tid->retry_q and
> > sets tid->clear_ps_filter, so they are retransmitted until they get
> > through.
> >
> > The result is downlink loss to awake non-WMM stations, while WMM/HT
> > stations on the same radio are unaffected. On a QCA9563 AP with
> > ESP8266 clients this caused 20-45% ping loss, with two TXERR_FILT
> > completions per lost frame and no XRETRY failures.
> >
> > Set CLRDMASK on every non-aggregate frame. This restores the
> > behaviour from before commit 5519541d5a5f ("ath9k: fix powersave
> > frame filtering/buffering in AP mode") for the non-aggregate path
> > only. The trade-off is that non-aggregate frames already queued in
> > hardware when a station enters powersave may be sent to the sleeping
> > station instead of being filtered.
> >
> > Assisted-by: LLM
> > Signed-off-by: Tomas Tonhauser <t.tonhauser@pobox.sk>
> > ---
> > RFC: is this direction acceptable, or is one of the alternatives
> > below preferred?
> 
> Hmm, no, I don't think unconditionally clearing the filter is the right
> thing to do. See below.

Understood, thanks for looking at it.

> 
> > Setup: TP-Link EAP225 v3 (QCA9563, 2.4 GHz), OpenWrt 25.12.5,
> > backports 6.18.26. Clients: ESP8266 running Tasmota, modem sleep
> > disabled, associated without WMM (legacy rates).
> >
> > Ping from the AP to one client, 30 packets, 14 lost:
> >
> >   station "tx failed":             +14
> >   station "tx retries":            +2
> >   ath9k/xmit BE "TXERR Filtered":  +27
> >   ath9k/xmit BE "MPDUs XRetried":  +0
> >
> > A second run: 12 lost, Filtered +28, XRetried +0.
> >
> > Ruled out:
> >  - Client powersave: PS_STA never set in debugfs station flags, and a
> >    monitor capture showed no client frames with the PM bit set.
> >  - airtime_flags=0, aql_enable=0, nohwcrypt=1: no change.
> >  - RF: signal -50..-64 dBm; a WMM/HT client on the same radio has
> >    0 tx failed out of ~10k frames; the same ESP8266 hardware behind
> >    an ath10k AP has no loss.
> >
> > With the patch: 500 pings to each of five ESP8266 clients, 0 lost.
> >
> > Open question: what sets the destination mask for stations that are
> > awake and never hit XRETRY? 5519541d5a5f removed an unconditional
> > CLRDMASK commented "needed for crypto errors", so the hardware may
> > set it in other cases too.
> 
> This is a good question. Maybe Felix knows?
> 
> Regardless, of your alternatives:
> 
> > Alternatives:
> >  1. Set CLRDMASK only when the station is not sleeping.
> >  2. Re-queue filtered non-aggregate frames in ath9k for awake
> >     stations, like the aggregate path does.
> >  3. Allow more than one software retry in
> >     ieee80211_handle_filtered_frame() for awake stations.
> 
> I think 2. makes the most sense. In fact, AFAICT, there is currently
> *no* software retry logic for non-aggregated frames in ath9k? So you hit
> it due to this weird filtering issue, but presumably random interference
> can also just lead to losses if they exhaust the hardware retry chain.
> But maybe this is not something that's noticeable because the hardware
> retry chain is usually enough? Do you notice any errors/retries in your
> AP stats after applying the fix (in normal usage, not just with a ping
> test)?

AP uptime with the patch is ~20 days, normal usage (mostly MQTT,
plus OTA firmware updates of all ESP devices early on).
Apart from ESP's and the camera (which are fixed), there are mobile
devices which come and go.

Per station (counters since association, ~19 days):
  10 x ESP8266 (non-WMM): tx failed 21..84 each,
                          0.018-0.057% of tx packets,
                          signal -50..-83 dBm, many hw retries
  ESP32 (WMM/HT):         1 failed / 1.8M tx packets
  IP camera (WMM/HT):     0 failed / 268k tx packets

ath9k xmit, BE queue, 20 days:
  MPDUs Completed:   3776047   MPDUs XRetried:   6130 (0.16%)
  AMPDUs Completed:  111572010 AMPDUs XRetried:  4605
  TXERR Filtered:    343

So the filtering losses are gone, but non-aggregated frames still
fail after the hardware retry chain far more often than aggregated
ones, which matches your point about missing software retries for
them.

> 
> Anyway, I don't think it's unreasonable to add the same retry logic to
> non-aggregated frames that we have for aggregated ones, and the retry_q
> seems like the simplest way to do that.

I'll work on re-queueing failed/filtered non-aggregate frames on
tid->retry_q for awake stations and send a v2.

> 
> -Toke

Thanks,
Tomas