[PATCH 02/58] NAN_DE: Fix SSI parsing in SDA (move to start)

[Jouni Malinen]

On Tue, Feb 24, 2026 at 10:48:26AM +0000, Otcheretianski, Andrei wrote:
> Actually, I don't really know who uses this APIs and whether it is going to be a problem.

The current implementation in hostap.git is only for USD and USD is
required to use SDEA for sending the SSI, so USD-only device to USD-only
device cases should have no impact from changes here. In theory, there
could a full NAN Device (i.e., not USD only) that could send SSI in SDA
and that could make a USD-only device confused (regardless of this
change). That specific case was the main reason why added this parsing
of SSI from SDA as an option in the initial USD implementation. That
said, I do agree that the specification does not say anything about the
OUI/subtype header being included in the SDA case. There is nothing
about the implied Service Protocol Type for this case either, so it is
not exactly clear how this is supposed to be working in the upper layer
interface.. For the cases that do use a specific Service Protocol Type
value, SDEA is explicitly mentioned to be used for sending SSI.

> We have encountered this issue with sync NAN DE testing and in this case SSI wasn't parsed at all.
> I guess, we can also have "else if" here instead to keep it backward compatible, though I think it should be done only if someone complains about it.
> Anyway, I can resend it with else if, or if you prefer you can change it yourself.

I think I'm fine leaving this change as-is for now and just add some
more notes to the commit message to justify the change. I could not
determine what the specification is trying to say for this specific case
vs. SSI in SDEA cases, so it is not clear what the correct and expected
behavior would be. Anyway, this can be changed in the future should a
real deployed case be reported to be impacted.

All that said, this will still leave the upper layer interfaces somewhat
confusing with the srv_proto_type being left to 0 which is a reserved
value for the SDEA case while still using the same interface for
indicating the received SSI regardless of whether it was from an SDA or
an SDEA. That might benefit from some clarification to make it more
obvious to upper layers that the SSI in the SDA case does not actually
indicate any particular Service Protocol Type value.

-- 
Jouni Malinen                                            PGP id EFC895FA