[PATCH 3/4] gas_query: retry GAS comeback requests instead of failing

[Gustavo Bertoli]

On Tue, Aug 4, 2026 at 10:36 AM Jouni Malinen <j at w1.fi> wrote:
> What is behind this TX failure case? Is this that "transient TX failure"
> from the commit message? I can understand a missed comeback response,
> but when would this TX operation fail?

Yes. The comeback request can be handed to offchannel_send_action()
just after the remain-on-channel window has lapsed, and the driver
then rejects the off-channel TX synchronously, so it never reaches
gas_query_tx_status(). Today that ends the query, as does the
asynchronous TX failure; with comeback_recover set both become a
bounded retry, and the retry succeeds once the next ROC window is
armed. Seen repeatedly on rtw88 and ath9k_htc, not reproducible
under hwsim.

> Is the "duplicate fragment" case referring to functionality from patch
> 1? If so, that gives even more reason for my comments on that patch if
> it does indeed need changes on the peer device as well.

Yes, it is the requester-side counterpart of the patch 1 resend. With
only one side updated the unpatched peer still sees valid GAS frames,
and the cases that side cannot recover still end the exchange, as
they do today. For example, a patched requester retrying the same
dialog token against an unpatched responder stops on the existing
unexpected-frag_id check (PEER_ERROR), where the current code fails
through its one-shot new-token restart instead. The retry is opt-in
for the DPP certBag exchange only.

Gustavo