Update to NCS3.0.0 broke wifi WPA2-PSK connect?

[BrianW]

Custom PCB with nrf5340/nrf7002. Currently was using NCS2.9.0, with WPA2-PSK connection to the wifi.

While trying to enable use of WPA2-Enterprise, I updated to NCS3.0.0 (to see if the increased flash requirement of around 45kB! was perhaps less). This turned out to be WAY worse (another 49kB on top for identical prj.conf), but also broke the WP2-PSK connection it seems?

Previous it would connect fine, but now it times out and I see these logs:

[00:02:21.108,764] <err> wpa_supp: Error in pbkdf2_sha1()
[00:02:21.110,382] <err> wpa_supp: Line 0: invalid key_mgmt 'SAE'

Any idea what these mean? I previously had the SAE log from time to time : I assumed this is for WPA3 with SAE key exchange which I wasn't using (WPA2-PSK) and it didn't block the connection.

If anyone has any ideas about how to trim down the wifi stack usage also I'd be interested too as it no longer fits in the flash on my nrf5340 (and yes, I already have the nrf70 fw and all other mcyboot slots in a external flash...)

[BrianW]

BrianW said:

If you build just wifi-sta sample with WPA2 enterprise (and not even an MQTT or HTTP client in that sample) you will find the application size is over 350kB....

Just built wifi-sta NCS2.9.0, just added to the prj.conf:

# WPA-PSK, WPA2-Enterprise, WPA3-SAE for at least EAP-TLS

CONFIG_WIFI_NM_WPA_SUPPLICANT_CRYPTO_ENTERPRISE=y

CONFIG_WIFI_NM_WPA_SUPPLICANT_WPA3=y

# Only support EAP TLS method

CONFIG_EAP_ALL=n

CONFIG_EAP_TLS=y

This gives an image size of around 640kB - with basically NO application code in it!

[5/10] Performing build step for 'wifi_sta'
[10/434] Generating include/generated/zephyr/version.h
-- Zephyr version: 3.7.99 (C:/ncs/v2.9.0/zephyr), build: v3.7.99-ncs2
[434/434] Linking C executable zephyr\zephyr.elf
Memory region Used Size Region Size %age Used
FLASH: 645196 B 1 MB 61.53%
RAM: 225780 B 448 KB 49.22%
IDT_LIST: 0 GB 32 KB 0.00%

This is squeezable (put nrf70 fw into external flash, remove all logging from WPA) but still, it casts a doubt on the reality of using the nrf5340 with just 1Mb of internal flash for any real wifi based application....

[BrianW]

Update : this image did not manage to connect to a wifi AP; turns out it did not include the nrf70 fw (sysbuild issue).

Final image size (for wifi_sta sample with WPA2 enterprise enabled) is:

[7/7] Linking C executable zephyr\zephyr.elf
Memory region Used Size Region Size %age Used
FLASH: 803188 B 1 MB 76.60%
RAM: 414512 B 448 KB 90.36%
IDT_LIST: 0 GB 32 KB 0.00%

It also required as you will note substantial increases in the heap size and stack sizes to be able to run.

WPA2-PSK and WPA3-SAE work with this image;  however, I cannot get WPA2 Enterprise with EAP-TLS to connect... I will open a seperate ticket for this issue.

[BrianW]

Elfving, any recommendation on reducing the wpa_supp code size here? 

Question : would it possible to run the entire wpa_supp code module directly from an external flash partition, connected on QSPI as this supports XIP? Anyone done this and got a build process that does it?

[Simonr]

Hi Brian

Sorry about the late reply, but we've had a bank holiday here in Norway, and now Håkon is out of office, so I have taken over this ticket. 

From the latest replies here it seems like you've moved the WPA enterprise issue to a separate ticket, as the initial problem here was resolved, and now we should focus on memory optimization here, correct? 

Unfortunately the WI-Fi stack is quite considerable with the STA mode added, you can see the Wi-Fi memory requirements here, as well as some suggestions on how to lower the memory footprint. https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/test_and_optimize/optimizing/memory.html#wi-fi 

Regarding running the entire WPA_SUPP module from an external flash, that would for one require that you don't use the QSPI on the nRF5340 for the nRF7002 connection, which is the default operation mode for an nRF5340 + nRF7002 design. But if you use the regular SPI for nRF7002, and then the QSPI and XIP to have application code on (like the wpa supp module) I think that should be feasible, but I can't say I know if it has been done before.

Best regards,

Simon

[BrianW]

Simonr said:

From the latest replies here it seems like you've moved the WPA enterprise issue to a separate ticket, as the initial problem here was resolved, and now we should focus on memory optimization here, correct?

I suspect the problem (failing to connect with WPA2-PSK on NCS3.0.0) is due to the mbedtls memory requirement, but I haven't had the time to try again with different heap configs... 

Simonr said:

Regarding running the entire WPA_SUPP module from an external flash, that would for one require that you don't use the QSPI on the nRF5340 for the nRF7002 connection, which is the default operation mode for an nRF5340 + nRF7002 design. But if you use the regular SPI for nRF7002, and then the QSPI and XIP to have application code on (like the wpa supp module) I think that should be feasible, but I can't say I know if it has been done before.

Our custom board uses the connections used on the nrf5340 DK, ie the flash is on QSPI and the nrf7002 on the regular SPI. This works ok and optimises the speed towards the flash rather than the network which is better for our application.

Running the wap_supp module as XIP from the external flash would be VERY useful - external flash size can be MUCH bigger than the internal, and as this code is executed only for the connection phase (I think) the speed hit won't be a problem. It would be very useful to have an example build setup for the wifi_sta sample that does this, in the same way as the examples of putting the nrf70 FW in the external flash (including as an XIP function...)

Any chance of Nordic creating such a validated sample to help with this?