Re: Interop problem with Quantum Fiber WiFi7 pods (duplicate RSNXE IE)

[James Prestwood <prestwoj@gmail.com>]

Hi,

On 10/2/24 10:08 AM, Vivek Das Mohapatra wrote:
> Hi - we've had reports of an incompatibility between network manager and
> the wifi7 hardware mentioned when using iwd as the backend.
>
> From what we've been able to tell:
>
> validate_mgmt_ies() fails
> cause: disallowed duplicate IEs in the AssocResponse frame
>
> We appear to have two dupes:
>
> 221 - IE_TYPE_VENDOR_SPECIFIC - allowed

This makes sense.

> 244 - IE_TYPE_RSNX - not allowed as a dup.

This does not. The issue being which one do we use? The first, second, 
Nth element? This is definitely an AP problem.

>
> We checked IEEE 80211-2020.pdf couldn't find specific details about IEs
> that can be duplicated vs the ones that can’t.
> [ Sections 9.4.2.1 and 9.4.2.241 ]
I don't remember there being anything in the spec that dictates which 
IEs can have duplicantes but IWD has this restriction for all elements 
except those that make sense to have duplicates, like vendor specific, 
neighbor reports, etc.
>
> We've tried various devices and software combinations (linux and non)
> and it seems to be an interop problem with iwd specifically - we think 
> adding IE_TYPE_RSNX to the allowed dups list in validate_mgmt_ies should
> do the trick.
Denis will have the final say, but I would say if we are to allow the 
RSNX element to have a duplicate it should include a warning indicating 
the AP is buggy, and a comment in the code with the specific AP/vendor 
information so we know why we added this case.
>
> To summarise:
>
>  - nm + iwd (v2.14) cannot auth against a Quantum Fiber WiFi7 pod
>  - there's a duplicate IE in the assocresponse which iwd is rejecting
>  - we think that IE should be allowed as a dup
>  - nm + wpa_supplicant seems to work
>  - we tried some non-linux device and they were also able to auth
>
> Does that sound like a reasonable fix? Do you want a patch?

Thanks,

James