AW: IWD 2.20 does not support Fast Roaming with NXP 88W9098 chipset

AW: IWD 2.20 does not support Fast Roaming with NXP 88W9098 chipset

[Dierk.Modrow]

Hello James,

we tried to implement 802.11r roaming with IWD 2.20 using a NXP 88W9098 chipset from H&D Wireless as client (using out of kernel tree driver of NXP moal/mlan -> FULLMAC) and failed.

First problem seems to be an error 'iwd[28112]: Could not register frame watch type 00b0: -22'
It's the call netdev[5540]:       frame_watch_add(wdev, 0, 0x00b0, auth_ft_response_prefix,
                                                sizeof(auth_ft_response_prefix),
                                                netdev_ft_auth_response_frame_event, netdev, NULL);

I traced it through kernel /net/wireless to cfg802_11 and the NXP driver and found a problem in the driver capabilities setting so that NL8011CMD_REGISTER request was already denied in the kernel.
(see analysis_register_frame_type.txt). Having applied the patch zz_ft_auth_register_bug.patch to the driver the error above has gone.

PROBLEM

The first association with the FT-enabled AP is ok, but when the first FT-authentication occurs, it fails with

Sep 26 13:00:34 sew-mnc-51321 iwd[28112]: ../iwd/src/ft.c:ft_send_authenticate()
Sep 26 13:00:34 sew-mnc-51321 iwd[28112]: ../iwd/src/netdev.c:netdev_ft_frame_cb() Failed to send FT-Frame

In IWMON-log the NL8011CMD_FRAME with the FT authentication.req fails with EINVAL:

Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]: < Request: Frame (0x3b) len 200 [ack]                                 30.060808
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:     Interface Index: 9 (0x00000009)
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:     Wiphy Frequency: 5240 (0x00001478)
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:     Frame: len 173
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         Frame Type: 0x00b0
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:             Type: Management (0)
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:             Authentication:
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                 Frame Control: protocol: 00 type: 00 subtype: 11 to: 00 from: 00 more_frags: 00
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                     retry: 00 power_mgmt: 00 more_data: 00 protected: 00 order: 00
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                 Duration: 0
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                 Address 1 (RA): 38:4B:24:96:05:38
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                 Address 2 (TA): 78:C4:0E:E0:18:60
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                 Address 3: 38:4B:24:96:05:38
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                 Fragment Number: 0
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                 Sequence Number: 0
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                 Algorithm: FT (seq: 1, status: 0)
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         b0 00 00 00 38 4b 24 96 05 38 78 c4 0e e0 18 60  ....8K$..8x....`
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         38 4b 24 96 05 38 00 00 02 00 01 00 00 00 30 26  8K$..8........0&
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f  ................
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         ac 04 00 00 01 00 18 8c 0a 27 37 f5 7d a2 6d 33  .........'7.}.m3
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         53 fc 7b 8e 83 e1 36 03 00 01 00 37 60 00 00 00  S.{...6....7`...
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 24  ...............$
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         ca bc 3e 62 db c6 0f c5 23 8a 7d f9 cf 68 d3 fb  ..>b....#.}..h..
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         08 14 16 34 4c 12 86 66 b0 c4 82 fe 54 fb e7 03  ...4L..f....T...
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         0c 33 38 34 62 32 34 39 36 30 35 32 30           .384b24960520
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:     Offchannel TX OK: true
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]: > Response: Frame (0x3b) len 4                                        30.060851
Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:     Status: Invalid argument (22)

A concurrent setup with wpa_supplicant V2.10 does work, but a look on IWMON yielded, that wpa_supplicant uses NL8011CMD_AUTHENTICATE with different NL80211 attributes whilst iwd uses NL8011CMD_FRAME with the full 802.11 ft_authenticate_frame as value of ATTR_FRAME.

Does wpa_supplicant use another NL8011 API for FT-Authenticate / FT-Associate than iwd?

Another short try with a QCA chipset using ath11k (SOFTMAC) seems to be working with IWD 2.20 and FT-transition ...

I have attached different IWMON logs as PCAP files:
nl80211#wpa-supplicant-good.pcap              Good: FT-transition with wpa_supplicant V2.10  -> Frame 200: ft_authenticate, Frame: 201: Response to ft_authenticate, Frame 204: ft_associate, Frame 208: Response to ft_associate

nl80211#iwd_register_fail_ft_fail.pcap          Bad: frame registration in iwd 2.20 fails, FT-transition fails -> Frame 90: register_frame type auth, Frame 91: Response to register (EINVAL), Frame 294: ft_authenticate, Frame: 295: Response to ft_authenticate (EINVAL)

nl80211#iwd_register_ok_ft_fail.pcap           Bad: frame registration in iwd 2.20 succeeds, FT-transition fails -> Frame 158: register_frame type auth, Frame 159: Response to register (SUCCESS), Frame 531: ft_authenticate, Frame 532: Response to ft_authenticate (EINVAL)

I also added a sorted log file containing iwd traces, iwmon text logs and kernel msgs (of the NXP driver): resorted_logs_of_iwd_ft_connection_trial#3.txt


We would like to use iwd instead of wpa_supplicant so any help would be appreciated!

With best regards
Dipl.-Ing. Dierk Modrow
Development Engineer
Development Electronics -
Industrial Controller & Communication 2 (DE-ICC2)

SEW-EURODRIVE GmbH & Co KG
Ernst-Blickle-Str. 42
76646 Bruchsal

T +49 7251 75-5123
F +49 7251 75-505123
mailto:dierk.modrow@sew-eurodrive.de

https://www.sew-eurodrive.de


________________________________


SEW-EURODRIVE GmbH & Co KG
Kommanditgesellschaft, Sitz: Bruchsal, RG Mannheim HRA 230970
Komplementärin: SEW-EURODRIVE Verwaltungs-GmbH, Sitz: Bruchsal, RG Mannheim HRB 230207

Geschäftsführender Gesellschafter: Jürgen Blickle
Geschäftsführung: Jürgen Blickle (Vorsitzender), Dr. Jörg Hermes, Dr. Hans Krattenmacher, Christian Mayer, Johann Soder

Re: AW: IWD 2.20 does not support Fast Roaming with NXP 88W9098 chipset

[James Prestwood]

Hi Dierk,

On 10/10/24 6:49 AM, Dierk.Modrow@sew-eurodrive.de wrote:
> Hello James,
>
> we tried to implement 802.11r roaming with IWD 2.20 using a NXP 88W9098 chipset from H&D Wireless as client (using out of kernel tree driver of NXP moal/mlan -> FULLMAC) and failed.
Are you sure its a fullmac card?
>
> First problem seems to be an error 'iwd[28112]: Could not register frame watch type 00b0: -22'
> It's the call netdev[5540]:       frame_watch_add(wdev, 0, 0x00b0, auth_ft_response_prefix,
>                                                  sizeof(auth_ft_response_prefix),
>                                                  netdev_ft_auth_response_frame_event, netdev, NULL);
>
> I traced it through kernel /net/wireless to cfg802_11 and the NXP driver and found a problem in the driver capabilities setting so that NL8011CMD_REGISTER request was already denied in the kernel.
> (see analysis_register_frame_type.txt). Having applied the patch zz_ft_auth_register_bug.patch to the driver the error above has gone.
>
> PROBLEM
>
> The first association with the FT-enabled AP is ok, but when the first FT-authentication occurs, it fails with
>
> Sep 26 13:00:34 sew-mnc-51321 iwd[28112]: ../iwd/src/ft.c:ft_send_authenticate()
> Sep 26 13:00:34 sew-mnc-51321 iwd[28112]: ../iwd/src/netdev.c:netdev_ft_frame_cb() Failed to send FT-Frame
>
> In IWMON-log the NL8011CMD_FRAME with the FT authentication.req fails with EINVAL:
>
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]: < Request: Frame (0x3b) len 200 [ack]                                 30.060808
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:     Interface Index: 9 (0x00000009)
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:     Wiphy Frequency: 5240 (0x00001478)
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:     Frame: len 173
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         Frame Type: 0x00b0
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:             Type: Management (0)
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:             Authentication:
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                 Frame Control: protocol: 00 type: 00 subtype: 11 to: 00 from: 00 more_frags: 00
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                     retry: 00 power_mgmt: 00 more_data: 00 protected: 00 order: 00
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                 Duration: 0
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                 Address 1 (RA): 38:4B:24:96:05:38
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                 Address 2 (TA): 78:C4:0E:E0:18:60
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                 Address 3: 38:4B:24:96:05:38
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                 Fragment Number: 0
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                 Sequence Number: 0
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:                 Algorithm: FT (seq: 1, status: 0)
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         b0 00 00 00 38 4b 24 96 05 38 78 c4 0e e0 18 60  ....8K$..8x....`
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         38 4b 24 96 05 38 00 00 02 00 01 00 00 00 30 26  8K$..8........0&
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f  ................
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         ac 04 00 00 01 00 18 8c 0a 27 37 f5 7d a2 6d 33  .........'7.}.m3
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         53 fc 7b 8e 83 e1 36 03 00 01 00 37 60 00 00 00  S.{...6....7`...
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 24  ...............$
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         ca bc 3e 62 db c6 0f c5 23 8a 7d f9 cf 68 d3 fb  ..>b....#.}..h..
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         08 14 16 34 4c 12 86 66 b0 c4 82 fe 54 fb e7 03  ...4L..f....T...
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:         0c 33 38 34 62 32 34 39 36 30 35 32 30           .384b24960520
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:     Offchannel TX OK: true
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]: > Response: Frame (0x3b) len 4                                        30.060851
> Sep 26 13:00:34 sew-mnc-51321 iwmon[28111]:     Status: Invalid argument (22)
>
> A concurrent setup with wpa_supplicant V2.10 does work, but a look on IWMON yielded, that wpa_supplicant uses NL8011CMD_AUTHENTICATE with different NL80211 attributes whilst iwd uses NL8011CMD_FRAME with the full 802.11 ft_authenticate_frame as value of ATTR_FRAME.
Generally fullmac cards don't let you use CMD_AUTHENTICATE, but the only 
card I have experience with is brcmfmac. IWD doesn't use 
CMD_AUTHENTICATE because its intolerant of failures, if the AP 
ignores/rejects the FT attempt you have to fully disconnect. IWD instead 
uses CMD_FRAME which can fail and we can proceed to another BSS. 
Apparently though your driver doesn't support CMD_FRAME nor registration 
for auth frames.
>
> Does wpa_supplicant use another NL8011 API for FT-Authenticate / FT-Associate than iwd?
>
> Another short try with a QCA chipset using ath11k (SOFTMAC) seems to be working with IWD 2.20 and FT-transition ...
>
> I have attached different IWMON logs as PCAP files:
> nl80211#wpa-supplicant-good.pcap              Good: FT-transition with wpa_supplicant V2.10  -> Frame 200: ft_authenticate, Frame: 201: Response to ft_authenticate, Frame 204: ft_associate, Frame 208: Response to ft_associate
>
> nl80211#iwd_register_fail_ft_fail.pcap          Bad: frame registration in iwd 2.20 fails, FT-transition fails -> Frame 90: register_frame type auth, Frame 91: Response to register (EINVAL), Frame 294: ft_authenticate, Frame: 295: Response to ft_authenticate (EINVAL)
>
> nl80211#iwd_register_ok_ft_fail.pcap           Bad: frame registration in iwd 2.20 succeeds, FT-transition fails -> Frame 158: register_frame type auth, Frame 159: Response to register (SUCCESS), Frame 531: ft_authenticate, Frame 532: Response to ft_authenticate (EINVAL)
>
> I also added a sorted log file containing iwd traces, iwmon text logs and kernel msgs (of the NXP driver): resorted_logs_of_iwd_ft_connection_trial#3.txt
>
>
> We would like to use iwd instead of wpa_supplicant so any help would be appreciated!
At this point in time looking at the above logs it appears IWD isn't 
compatible with this out of tree driver due to the requirement to use 
CMD_AUTHENTICATE. I've thought about adding this back in for "weird" 
drivers that have problems with how IWD works. For the near term we 
could try and detect this case, via the CMD_REGISTER failure, and 
disable FT entirely for drivers like this. You'd be stuck with only 
reassociation but at least the device could roam. I can get you a patch 
to try soon.
>
> With best regards
> Dipl.-Ing. Dierk Modrow
> Development Engineer
> Development Electronics -
> Industrial Controller & Communication 2 (DE-ICC2)
>
> SEW-EURODRIVE GmbH & Co KG
> Ernst-Blickle-Str. 42
> 76646 Bruchsal
>
> T +49 7251 75-5123
> F +49 7251 75-505123
> mailto:dierk.modrow@sew-eurodrive.de
>
> https://www.sew-eurodrive.de
>
>
> ________________________________
>
>
> SEW-EURODRIVE GmbH & Co KG
> Kommanditgesellschaft, Sitz: Bruchsal, RG Mannheim HRA 230970
> Komplementärin: SEW-EURODRIVE Verwaltungs-GmbH, Sitz: Bruchsal, RG Mannheim HRB 230207
>
> Geschäftsführender Gesellschafter: Jürgen Blickle
> Geschäftsführung: Jürgen Blickle (Vorsitzender), Dr. Jörg Hermes, Dr. Hans Krattenmacher, Christian Mayer, Johann Soder

Re: AW: IWD 2.20 does not support Fast Roaming with NXP 88W9098 chipset

[Denis Kenzior]

Hi James,

On 10/10/24 9:23 AM, James Prestwood wrote:
> Hi Dierk,
> 
> On 10/10/24 6:49 AM, Dierk.Modrow@sew-eurodrive.de wrote:
>> Hello James,
>>
>> we tried to implement 802.11r roaming with IWD 2.20 using a NXP 88W9098 
>> chipset from H&D Wireless as client (using out of kernel tree driver of NXP 
>> moal/mlan -> FULLMAC) and failed.
> Are you sure its a fullmac card?

It is.  But they're likely doing something similar to this:
https://lore.kernel.org/all/20240704033001.603419-2-yu-hao.lin@nxp.com/

Perhaps the Marvell / NXP maintainers can be convinced to add support for 
CMD_FRAME path as well.

Regards,
-Denis

Re: AW: IWD 2.20 does not support Fast Roaming with NXP 88W9098 chipset

[Denis Kenzior]

Hi Dierk,

> we tried to implement 802.11r roaming with IWD 2.20 using a NXP 88W9098 chipset from H&D Wireless as client (using out of kernel tree driver of NXP moal/mlan -> FULLMAC) and failed.

Is the code for this out of tree driver available somewhere?

Regards,
-Denis

Re: AW: IWD 2.20 does not support Fast Roaming with NXP 88W9098 chipset

[James Prestwood]

On 10/10/24 8:32 AM, Denis Kenzior wrote:
> Hi James,
>
> On 10/10/24 9:23 AM, James Prestwood wrote:
>> Hi Dierk,
>>
>> On 10/10/24 6:49 AM, Dierk.Modrow@sew-eurodrive.de wrote:
>>> Hello James,
>>>
>>> we tried to implement 802.11r roaming with IWD 2.20 using a NXP 
>>> 88W9098 chipset from H&D Wireless as client (using out of kernel 
>>> tree driver of NXP moal/mlan -> FULLMAC) and failed.
>> Are you sure its a fullmac card?
>
> It is.  But they're likely doing something similar to this:
> https://lore.kernel.org/all/20240704033001.603419-2-yu-hao.lin@nxp.com/
Ugh, they just can't fully commit to being a "normal" driver, can they.
>
> Perhaps the Marvell / NXP maintainers can be convinced to add support 
> for CMD_FRAME path as well.
>
> Regards,
> -Denis
>

Re: AW: IWD 2.20 does not support Fast Roaming with NXP 88W9098 chipset

[James Prestwood]

H Dierk,

<snip>
>> I also added a sorted log file containing iwd traces, iwmon text logs 
>> and kernel msgs (of the NXP driver): 
>> resorted_logs_of_iwd_ft_connection_trial#3.txt
>>
>>
>> We would like to use iwd instead of wpa_supplicant so any help would 
>> be appreciated!
> At this point in time looking at the above logs it appears IWD isn't 
> compatible with this out of tree driver due to the requirement to use 
> CMD_AUTHENTICATE. I've thought about adding this back in for "weird" 
> drivers that have problems with how IWD works. For the near term we 
> could try and detect this case, via the CMD_REGISTER failure, and 
> disable FT entirely for drivers like this. You'd be stuck with only 
> reassociation but at least the device could roam. I can get you a 
> patch to try soon.

I just sent a few patches to the mailing list. Would you be able to try 
these out and verify the device roams? Note, its going to choose 
reassociation now (if they work as intended), not FT. But any roaming is 
better than nothing at least. Longer term we can think about using 
CMD_AUTHENTICATE for drivers like this.

Thanks,

James

AW: AW: IWD 2.20 does not support Fast Roaming with NXP 88W9098 chipset

[Dierk.Modrow]

Hi James,

thank you for the patches. I will try it as a first workaround.

Thanks,

Dierk

Von: James Prestwood <prestwoj@gmail.com>
Gesendet: Freitag, 11. Oktober 2024 16:58
An: Modrow, Dierk <Dierk.Modrow@sew-eurodrive.de>; iwd@lists.linux.dev
Betreff: Re: AW: IWD 2.20 does not support Fast Roaming with NXP 88W9098 chipset

H Dierk, <snip> >> I also added a sorted log file containing iwd traces, iwmon text logs >> and kernel msgs (of the NXP driver): >> resorted_logs_of_iwd_ft_connection_trial#3. txt >> >> >> We would like

H Dierk,

<snip>
>> I also added a sorted log file containing iwd traces, iwmon text logs
>> and kernel msgs (of the NXP driver):
>> resorted_logs_of_iwd_ft_connection_trial#3.txt
>>
>>
>> We would like to use iwd instead of wpa_supplicant so any help would
>> be appreciated!
> At this point in time looking at the above logs it appears IWD isn't
> compatible with this out of tree driver due to the requirement to use
> CMD_AUTHENTICATE. I've thought about adding this back in for "weird"
> drivers that have problems with how IWD works. For the near term we
> could try and detect this case, via the CMD_REGISTER failure, and
> disable FT entirely for drivers like this. You'd be stuck with only
> reassociation but at least the device could roam. I can get you a
> patch to try soon.

I just sent a few patches to the mailing list. Would you be able to try
these out and verify the device roams? Note, its going to choose
reassociation now (if they work as intended), not FT. But any roaming is
better than nothing at least. Longer term we can think about using
CMD_AUTHENTICATE for drivers like this.

Thanks,

James


________________________________


SEW-EURODRIVE GmbH & Co KG
Kommanditgesellschaft, Sitz: Bruchsal, RG Mannheim HRA 230970
Komplementärin: SEW-EURODRIVE Verwaltungs-GmbH, Sitz: Bruchsal, RG Mannheim HRB 230207

Geschäftsführender Gesellschafter: Jürgen Blickle
Geschäftsführung: Jürgen Blickle (Vorsitzender), Dr. Jörg Hermes, Dr. Hans Krattenmacher, Christian Mayer, Johann Soder