Re: [PATCH wireless-next] wifi: mac80211: Fix ADDBA request rejection after MLD link removal

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2026-04-15 at 12:21 +0530, Manish Dharanenthiran wrote:
> From: Hari Naraayana Desikan Kannan <hnaraaya@qti.qualcomm.com>
> 
> Subsequent ADDBA requests from a non-AP MLD can be rejected with status
> 0x0025 (Request declined), preventing BA establishment. This happens
> because mac80211 checks the per-TID A-MPDU session's tid_rx pointer to
> detect timeout changes on ADDBA updates. For drivers that set
> SUPPORT_REORDERING_BUFFER, the reordering state is owned by the driver
> and tid_rx will be NULL, causing mac80211 to incorrectly decline the
> update.
> 
> This can occur during MLO link reconfiguration, where a non-AP MLD may
> remove one of its links while a Block Ack (BA) session is active. After
> the link is removed, ADDBA update requests sent on the remaining links
> are rejected, preventing BA establishment.
> 
> Fix this by calling drv_ampdu_action() on ADDBA updates when
> SUPPORT_REORDERING_BUFFER is set, so the driver can accept or reject the
> update based on its capabilities and allow BA to be established on the
> remaining links.

Pretty sure this will break drivers, particularly iwlwifi, if you don't
fix those first.

> Note: A similar fix has been proposed in [1]. This patch also fixes the
> issue mentioned there. The difference in approach is to keep a similar
> flow when the dialog_token matches. Previously only the timeout value
> is checked, updated that to check the timeout only for the hardware that
> doesn't set SUPPORT_REORDERING_BUFFER. In [1], it was changed to invoke
> driver unconditionally when SUPPORT_REORDERING_BUFFER is set.
> 
> https://lore.kernel.org/all/5806bab7e46506d3c300ab4eb66989d42936aeb0.1771323902.git.repk@triplefau.lt/
> 
What was wrong with the approach we discussed there, other than nobody
implementing it?

johannes