JorgeGzm opened a new pull request, #19461:
URL: https://github.com/apache/nuttx/pull/19461
## Summary
Two robustness fixes for the GD32VW553 port:
**1. Reject WPA3/SAE networks instead of crashing.** Associating to a WPA3
(SAE) network faulted inside the prebuilt vendor supplicant (load access
fault in the elliptic-curve math of the SAE handshake). The port is
WPA2-only, so refuse what the supplicant cannot complete:
- Undefine `CONFIG_WPA3_SAE` in the `build_config.h` shim. This activates
the vendor's own fallback in `wifi_netlink.c`: the SAE/OWE AKMs are
stripped from the connection config and the SAE auth algorithm is never
selected, so a WPA3-transition AP (WPA2/WPA3 mixed) now associates
through WPA2-PSK. The flag only gates code, not struct layout, so the
prebuilt libraries are unaffected.
- Refuse an SAE/OWE/802.1X-only network up front in the connect path with
`ENOTSUP` and a console message naming the unsupported AKM bitmap,
instead of an obscure association failure.
**2. Restart BLE advertising after disconnection.** A connection stops the
legacy advertising set and the vendor stack leaves it stopped, so after the
first central connected (or aborted the attempt) the device was never
discoverable again until a reset. Register a connection callback and
restart the advertising set with `ble_adv_restart()` on every
disconnection. This covers both the clean disconnect and the
aborted-connection case (an incomplete connection holds the link until the
supervision timeout, whose disconnection event then restarts the
advertising the same way).
## Impact
Only the GD32VW55x port (`arch/risc-v/src/gd32vw55x` and its board
documentation); no common code is changed. Behavior changes:
- A WPA3-transition network now associates through WPA2-PSK (it previously
crashed the supplicant).
- A WPA3(SAE)-only network is refused with `ENOTSUP` and a clear console
message (it previously crashed the supplicant).
- The BLE device stays discoverable across connections (it previously
required a reset after the first connection).
## Testing
Built the `wapi` and `ble` configurations; `nxstyle` is clean. Validated
on hardware (GD32VW553K-START).
```sh
./tools/configure.sh gd32vw553k-start:ble # wapi + BLE, exercises both
fixes
make -j
openocd -f openocd_gdlink.cfg \
-c "program nuttx.bin 0x08000000 verify reset exit"
```
### 1. WPA2 network (regression: still associates)
```
nsh> ifup wlan0
nsh> wapi psk wlan0 ******** 3
nsh> wapi essid wlan0 @GUZM 1
[0] (-29 dBm) CH= 1 BSSID=XX:XX:XX:XX:XX:XX SSID=@GUZM [RSN:WPA-PSK
CCMP/CCMP]
MAC: auth req send
MAC: auth rsp received, status = 0
MAC: assoc req send
MAC: assoc rsp received, status = 0
WPA: 4-1 received
WPA: 4-2 send
WPA: 4-3 received
WPA: 4-4 send
nsh> renew wlan0
nsh> ping -c 3 8.8.8.8
PING 8.8.8.8 56 bytes of data
56 bytes from 8.8.8.8: icmp_seq=0 time=21.0 ms
56 bytes from 8.8.8.8: icmp_seq=1 time=44.0 ms
56 bytes from 8.8.8.8: icmp_seq=2 time=11.0 ms
3 packets transmitted, 3 received, 0% packet loss, time 3003 ms
```
### 2. WPA3(SAE)-only network: refused with a clear error, no crash
Phone hotspot `wpa3test` configured as WPA3-Personal (SAE only):
```
nsh> wapi psk wlan0 12345678 3
nsh> wapi essid wlan0 wpa3test 1
gdwifi: 'wpa3test' offers no supported AKM (bitmap 0x200): WPA3/SAE, OWE and
802.1X are not supported, WPA2-PSK only
nsh> echo ALIVE
ALIVE
```
(Before this change: `EXCEPTION: Load access fault` in the `wifi_mgmt`
task. `0x200` is bit 9 = `MAC_AKM_SAE`. A refused connect also leaves a
previously established association untouched.)
### 3. WPA2/WPA3 transition network: associates through WPA2-PSK
Same hotspot switched to WPA2/WPA3 mixed mode; note the SAE AKM and MFP in
the beacon, and the plain WPA2 four-way handshake used:
```
nsh> wapi essid wlan0 wpa3test 1
[0] (-37 dBm) CH= 11 BSSID=XX:XX:XX:XX:XX:XX SSID=wpa3test [RSN:WPA-PSK,SAE
CCMP/CCMP][MFP:AES-128-CMAC]
MAC: auth req send
MAC: auth rsp received, status = 0
MAC: assoc req send
MAC: assoc rsp received, status = 0
WPA: 4-1 received
WPA: 4-2 send
WPA: 4-3 received
WPA: 4-4 send
nsh> renew wlan0
nsh> ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX at RUNNING mtu 1500
inet addr:10.28.126.72 DRaddr:10.28.126.23 Mask:255.255.255.0
nsh> ping -c 3 10.28.126.23
3 packets transmitted, 3 received, 0% packet loss, time 3003 ms
```
(Before this change this case also crashed: the supplicant selected SAE
whenever the AP offered it.)
### 4. BLE: repeated connect cycles from a Linux central (bleak)
Scan / connect / write / disconnect cycles, no board reset in between:
```
[cycle 1] advertising
[cycle 1] connect+write+disconnect OK
[cycle 2] advertising <- re-advertising after the clean disconnect
[cycle 3] advertising <- re-advertising after an aborted connection
```
Board console receives the writes:
```
nsh> BLE RX (7): final 1
```
(Before this change the device was no longer advertising after the first
connection and never became discoverable again until a reset.)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
