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

[Gustavo Bertoli]

On Tue, Aug 4, 2026 at 10:24 AM Jouni Malinen <j at w1.fi> wrote:
> 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.

The peer then requests the next fragment and receives the same
fragment again, which lands in the receiver's existing duplicate
handling: gas_query_rx_comeback() drops frag_id + 1 == next_frag_id as
a "possible retry of previous fragment", so the Fragment ID field
makes the retransmission detectable. Today either loss is terminal
anyway: any no-ACK mid-transfer drops the pending entry. These losses
occur across ROC dwell boundaries, after the driver's own retries are
exhausted, which is why the recovery is done at the GAS layer.

> 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).

Agreed, I will split it in v2 and place right after this rollback
patch; its commit message will describe the race and when it becomes
reachable.

Gustavo