[PATCH] gas_query: use announced comeback_delay for Comeback Response

Gustavo Bertoli gubertoli at gmail.com
Wed Jun 10 04:20:37 PDT 2026


> The wait for the GAS comeback happens before sending the GAS comeback
> request (see gas_query_tx_comeback_req_delay), not after having sent
> that frame.

Thanks for the review and clarifying. The pre-send wait in
gas_query_tx_comeback_req_delay already uses the server-announced
comeback_delay value.

> The client waits 1000 ms before sending the comeback request..

Confirmed, the pre-send wait works correctly. The original patch description
was wrong about where the failure occurs.

> Are you saying you don't see that wait before the comeback request is
> sent? If so, that needs to be fixed. It is not correct to wait a longer
> dynamic amount of time after having sent the comeback request.

No, the pre-send wait is not the issue.

The failure I observed is that DPP certBag responses exceed gas_frag_limit
and are split into two fragments. When the comeback TX for fragment 2
gets OFFCHANNEL_SEND_ACTION_FAILED (ROC window lapsed between
receiving fragment 1 and sending the follow-up), gas_query_tx_status() kills the
session immediately regardless of wait_comeback. The same happens on
NO_ACK, the watchdog is replaced with a timeout that fires unconditionally.

The original change to use comeback_delay for the RX wait window remains
applicable for this case.
I will update the patch to also add a retry path in gas_query_tx_status() for
NO_ACK and FAILED when wait_comeback is set, rather than killing the query.



More information about the Hostap mailing list