[PATCH 79/97] NAN: Add support for tracking the status of transmit requests

[Peer, Ilan]

Hi,

> -----Original Message-----
> From: Jouni Malinen <j at w1.fi>
> Sent: Saturday, May 9, 2026 10:29 AM
> To: Otcheretianski, Andrei <andrei.otcheretianski at intel.com>
> Cc: hostap at lists.infradead.org; vamsin at qti.qualcomm.com;
> maheshkkv at google.com; Peer, Ilan <ilan.peer at intel.com>
> Subject: Re: [PATCH 79/97] NAN: Add support for tracking the status of
> transmit requests
> 
> On Tue, Apr 28, 2026 at 11:06:20PM +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.
> 
> So this is all implementation-internal tracking? If so, why does this use
> CRC32? CRC was designed for error detected, but for identifying different
> blobs and it is not really suitable for uses where there could be issues with
> misidentification of two payloads either by accident or even worse, if there
> is any malicious construction of such payloads.
> 

Understood. I'll change the implementation to use SHA-256 which is more suitable
(collision resistance). I'll also add a check to reject requests for which there is already
a request with identical digest.

> > diff --git a/src/common/nan_de.c b/src/common/nan_de.c
> > +static u32 nan_de_track_tx_digest(const u8 *data, size_t len) {
> > +	return ieee80211_crc32(data, len);
> > +}
> 
> This feels a bit strange and not exactly robust way of identifying whether
> two blobs are identical. What would happen if two different requests would
> end up having the same digest value?

As I do not expect this to happen in practice, I'll add support to reject such requests.

Regards,

Ilan.