Well I did get this to work…..kinda
After finding this page
https://openwrt.org/docs/guide-user/network/wifi/wireless-tool/wireless.utilities
which suggested wpad replaces hostapd(author seems unsure however), I removed hostapdwhich allowed me to install wpad-basic-wolfssl.This resulted in a connection that I could actually use, at least sorta.
I did some digging and although morrownr recommends the device from the point of view of Linux support, they do not recommend using it for AP mode due to limited range owing to the design. It may still suffice for my needs (as a get out of jail card), but I have decided to wait for 25 stable before trying any further in the hope of a more stable experience with kernel 6.12.
I noticed that I might have been having problems due to my phone spoofing the MAC. In the log extract above, I hadn’t noticed earlier that the MAC changed after the first 2 entries (after that handle_assoc_cb STA not found entry). It also appears to be important to fix a channel, rather than leaving it set to auto. There are log entries for 2.4Ghz frequencies missing noise floor and other entries that seemed tangentially related to that but which are now lost after a reboot (failed to set beacon parameters or something similar).
I’m not sure how a properly integrated WiFi stack in OpenWrt handles channel management etc. Perhaps I am still missing some esoterica related to that.
Will hope for an easier experience on the newer kernel which would appear to be any day now.
Maybe the answer is to bite the bullet and buy an Alfa adapter, but will try 25.12 first.
Would still welcome any conjecture or details of how to properly add support for WiFi in OpenWrt, to a device that didn’t originally ship with the capability.
EDIT: I booted another OpenWrt device that has 25.12.0-RC5 and that uses wpad-basic-mbedtls, so I removed wpad-basic-wolfssl on the NanoPi R5S and installed wpad-basic-mbedtls. This apperas to have resolved quite a few issues, including needing to choose a channel rather than leaving it set to auto.
However, unplugging and replugging the USB adapter doesn’t restore the AP, so presently, it isn’t a working solution for occasional get-you-out-of-trouble use, unless permanently connected (which I wanted to avoid). When replugged, the device number is incremented by 1
kern.info kernel: [ 530.819146] usb 8-1: USB disconnect, device number 3
kern.info kernel: [ 543.815966] usb 8-1: new SuperSpeed USB device number 4 using xhci-hcd
Not sure how to handle that.
Also noticed this FWIW
Mon Feb 23 20:58:55 2026 daemon.notice netifd: radio0 (4848): Reference error: left-hand side expression is null
Mon Feb 23 20:58:55 2026 daemon.notice netifd: radio0 (4848): In /usr/share/hostap/wdev.uc, line 177, byte 14:
Mon Feb 23 20:58:55 2026 daemon.notice netifd: radio0 (4848):
Mon Feb 23 20:58:55 2026 daemon.notice netifd: radio0 (4848): `phy = phydev.phy;`
Mon Feb 23 20:58:55 2026 daemon.notice netifd: radio0 (4848): Near here ---^
Does anyone know of a way to preserve a USB device number when unplugging/replugging? (or to release the device number when unplugged so it is free for re-use?)