[BUG] wifi: mt76: mt7925: ADDBA SSN lags the hardware sequence number

[BUG] wifi: mt76: mt7925: ADDBA SSN lags the hardware sequence number

[Anders Kaseorg]

For about 30 s after associating with my AP, every SSH session from my 
laptop (Framework Laptop 13 with MT7925, kernel 7.3.0) is sluggish, with 
echoed keystrokes and command output arriving in bursts, delayed by half 
a second or more.  Specifically, because OpenSSH defaults to IPQoS=ef 
for interactive sessions, its packets get a TID distinct from most 
traffic; every TID stalls like this until it has carried 64 frames.

The cause is on both sides.  The MT7925 sends ADDBA requests whose 
Starting Sequence Number lags behind the sequence number the hardware 
actually uses for that TID, and the AP’s reorder buffer keeps waiting 
for the missing SN.

What I see, with a Linksys WRT3200ACM (Marvell 88W8964) as AP:

- By patching the AP’s mwlwifi driver to log the ADDBA SSN of every RX 
BA session from the MT7925, I find that after association, it’s 
consistently 0 for each TID.
- The client sends one QoS data frame on a TID before the session exists 
(mt7925_tx_check_aggr() starts the session from the TX completion of the 
first QoS data frame).  That frame uses SN 0.
- So the AP’s reorder window starts at SN 0, which never arrives within 
the session.  The 88W8964 firmware buffers every following frame of the 
TID until its ~500 ms timeout, which releases the buffered frames but 
doesn’t move the window start; only a frame beyond the window end (64 
frames later) does.

Reproduction recipe: right after association,

   ping -Q 0xb8 -i 0.02 -c 150 <AP>

(0xb8 = EF maps to TID 6, a TID nothing else uses).  Ping 1 is answered 
in ~1 ms (sent before the session).  Pings 2-26 are answered together 
~520 ms later, 27-50 together ~500 ms after that, and ping 65 (64 frames 
after ping 1) goes through immediately and releases 51-64.  Everything 
after that is fast.  Captures on both ends show the uplink frames 
reaching the AP’s network stack ~502 ms late; the downlink is fine.

The AP’s firmware is arguably at fault for not advancing the window on 
timeout (a mac80211 recipient would stall once, for at most its 100 ms 
reorder timeout).  But the originator should announce the SN of the next 
frame it will send under the agreement, here 1.

Cause, as far as I can tell: with SUPPORTS_TX_ENCAP_OFFLOAD the hardware 
assigns the sequence numbers of 802.3 frames, and mac80211’s 
sta->tid_seq[tid] never advances, so the SSN mac80211 puts in 
params->ssn for IEEE80211_AMPDU_TX_START stays 0.  mt7925 doesn’t 
override it.  mt7615 does, reading the TID’s SN from the WTBL 
(mt7615_mac_get_sta_tid_sn()).  mt7915, mt7921 and mt7996 use encap 
offload and don’t override it either, so they might have the same 
problem (not tested).

I’m happy to test any proposed patches.  I wasn’t able to fix it myself 
because I don't know where connac3 keeps the per-TID TX SN.

Anders

(Disclosure: I worked on this with help from an AI coding assistant. 
All measurements are from real hardware.)