[PATCH 1/3] NAN: Add support for tracking the status of transmit requests

[Peer, Ilan]

Hi,

> -----Original Message-----
> From: Jouni Malinen <j at w1.fi>
> Sent: Wednesday, May 20, 2026 12:43 PM
> To: Otcheretianski, Andrei <andrei.otcheretianski at intel.com>
> Cc: hostap at lists.infradead.org; maheshkkv at google.com;
> vamsin at qti.qualcomm.com; Peer, Ilan <ilan.peer at intel.com>
> Subject: Re: [PATCH 1/3] NAN: Add support for tracking the status of transmit
> requests
> 
> On Wed, May 13, 2026 at 09:58:59AM +0300, Andrei Otcheretianski wrote:
> > Extend the NAN Discovery Engine (DE) to track the status of transmit
> > requests coming from higher layers:
> >
> > - For transmit requests with valid cookie number, add the
> >   cookie and a digest of the transmitted frame to a list.
> > - Once a Tx status for a transmitted frame is received, search
> >   for the corresponding entry in the list of tracked frames,
> >   and when found report to the higher layer whether the frame
> >   was acknowledged or not.
> 
> I applied these three patches now to make progress with the pending NAN
> patches, but I'm wondering whether it would make more sense to modify the
> interface to higher layers to generate the cookie values within wpa_supplicant
> instead of getting them from the higher layers. Isn't the current design
> depending on the higher layers managing a pool of unique cookie values?
> wpa_supplicant could do that and the control interface command would simple
> get a parameter in for requesting TX status and the response to that control
> interface command would return the assigned cookie when that TX status was
> requested.

I've considered this option while working on this change, but decided to have this configured
by the higher layer, as I this cookie value is not useful/needed for the wpa_supplicant internal
logic (it is not aware of the frame data etc.), and I expect the higher layer to have some tracking
of the cookies one way or another. 

Regards,

Ilan.