[PATCH 1/4] gas_server: resend a response fragment after a lost ACK

[Jouni Malinen]

On Tue, Jun 23, 2026 at 05:57:14PM +0200, Gustavo Bertoli wrote:
> A fragmented GAS response advances its cursor as each fragment is handed to
> the driver, regardless of whether that fragment was ACKed. On a
> remain-on-channel rendezvous a fragment can be lost to dwell misalignment
> after the cursor has moved past it, so it was never resent and the transfer
> stalled. Track the previous offset and a tx_pending flag, and on a no-ACK TX
> status roll back and resend that fragment on the next Comeback Request.

What would happen if it is the ACK frame itself that is lost instead of
the frame carrying the fragment of the response? Sending the same
fragment ID in two different MMPDUs feels wrong and it is not clear what
the receiver might do when receiving that.

Working around this cleanly might require low-level operations that
would allow the same MMPDU to be transmitted additional times until an
ACK frame is received or a longer timeout is reached. That said, this
would be a bit inconvenient to implement since it would involve
potentially driver specific changes in kernel..

> A Comeback Request that arrives before the previous fragment's TX status has
> resolved is not yet known to be missed; resending then would supersede the
> still in-flight frame and discard its TX status. Wait for the status
> instead.

This feels like an independent change and it would be good to split into
a separate patch (i.e., that tx_pending tracking that is mentioned above
does not seem to be used at all for resending a prior fragment and it is
just for this part of the patch).

-- 
Jouni Malinen                                            PGP id EFC895FA