[PATCH 6/9] WNM: Implement ML handling of neighbor report entries

[Benjamin Berg]

On Fri, 2025-10-03 at 16:26 +0300, Jouni Malinen wrote:
> On Fri, Jul 18, 2025 at 01:01:02PM +0200, Benjamin Berg wrote:
> > diff --git a/wpa_supplicant/wnm_sta.c b/wpa_supplicant/wnm_sta.c
> > +static void wnm_parse_neighbor_report_multi_link(struct
> > neighbor_report *rep,
> > + u8 id, u8 elen, const u8 *pos)
> 
> > + /* The ML control should be all zeroes except for link ID. */
> > + if ((le_to_host16(ml->ml_control) &
> > +      ~BASIC_MULTI_LINK_CTRL_PRES_LINK_ID) != 0) {
> > + wpa_printf(MSG_DEBUG,
> > +    "WNM: Unsupported ML control: %04x",
> > +    le_to_host16(ml->ml_control));
> > + return;
> > + }
> 
> This is way too strict validation and is just asking for problems
> similarly to some earlier EHT cases that broke things when "new"
> fields
> were taken into use.. Some of these bits are reserved and might have
> different values in the future. In any case, there is not really any
> need for this check in the first place since the potential optional
> fields can be skipped based on the Common Info Length field without
> having to parse Common Info fields beyond the Link ID Info field.

It is true that I misread the specification and we need to ignore the
reserved bits. That said, the specification does say in REVmf D1.0
35.3.23 ("BSS transition management for MLDs"):

"""
 * If an AP MLD intends to provide a preference for a reported AP MLD
   without recommendations about specific affiliated APs, it shall:
    - ...
    - Set to 0 all subfields of the Presence Bitmap subfield.
    - ...
"""

And similarly requiring Link ID to be set if links are specified.

But, I am also OK with just not verifying that. Link ID Info is at the
start, so reading it is simple either way.


Note that the patch has some other problems, I'll submit a new version
with further WNM changes later.

Benjamin