ath12k: ML Association Response accepting a partner link is not transmitted when the 5 GHz link is 160 MHz (QCN6432, WLAN.WBE.1.4-01734)

[John Macias]

Hello,

On an AP MLD with a 2.4 GHz link and a 5 GHz link, an Association
Response that accepts the partner link is never transmitted when the
5 GHz link runs at 160 MHz. At 80 MHz the same response goes out in about
2 ms. Single-link responses at 160 MHz are transmitted normally, even
when they are larger than the two-link response.

Setup:
- GL.iNet GL-BE3600 (Slate 7): IPQ5332 (2.4 GHz link) + QCN6432
  (5 GHz link), ath12k AHB
- Firmware WLAN.WBE.1.4-01734-QCAHKSWPL_SILICONZ-1 (also what the
  vendor's current 4.10.1 image ships)
- OpenWrt, kernel 6.18.55, mac80211/ath12k from backports-7.2 with
  local patches (diagnostic logging and one REO descriptor flush
  change); hostapd 2026.08.07
- AP MLD: 2412 MHz EHT20 + 5180 MHz (channel 36), EAP-TLS
- Client: MediaTek MT7925 (two-link MLO)

What happens at 160 MHz:
- hostapd builds the accepting response (485 bytes, primary link and
  partner link status 0) about 4 ms after the request and submits it
  over WMI (return 0).
- The management TX completion arrives 185-236 ms later with
  status 1 (six observed cases: 185.4, 230.1, 235.9, 236.0, 228.3 and
  218.9 ms). No accepting response was seen in an external capture
  (capture absence only, not proof of no transmission).
- Meanwhile the client retries about 100 ms later. Without a hostapd
  change the retry gets a partner-link reject (295 bytes, which is
  transmitted), and the client associates on one link at 160 MHz
  (authentication, DHCP, traffic and 3-minute stability are fine).
- At 80 MHz (same channel, same client) the accepting response
  completes in about 2 ms with status 0 and both links come up.

Size is not the trigger: with a 200-byte vendor element added to every
Association Response (assocresp_elements), the single-link response
(about 495 bytes) is still transmitted at 160 MHz, while the two-link
responses still fail. A DFS-free 160 MHz channel could not be tested
(channel 149/163 is not allowed for AP mode by this firmware's
regulatory data), and an 80 MHz MLO link on a DFS channel (52) aborts
CAC after one second, so DFS involvement could not be isolated; at
160 MHz on channel 36 CAC completes and the link comes up.

So the failure appears tied to the partner-link setup on the 160 MHz
link around the time the response is queued, rather than to the frame
itself. I can provide full WMI/hostapd timelines, the frame bytes for the
80 and 160 MHz cases, and run test builds or additional logging on
this hardware.

Is this a known firmware limitation for QCN6432 at 160 MHz, or is there
something in the host-side peer/link setup ordering at 160 MHz that
could cause the firmware to drop the frame?

A related hostapd change (replacing the AP MLD's own stale link STA on
a retried association) is being sent to the hostap list separately; it
does not fix this, since the retried two-link response is not
transmitted either.

This analysis was prepared with the help of an AI assistant; all
measurements are from the hardware described above.

Thanks,
John