Skupsy

Well, I digged a little around this issue. It looks like a patch to the kernel driver of the xradio module is somewhat incomplete. So I patched the kernel and now the Wi-Fi works like a charm... well, not really (because of the XR819 module) but at least it gets the stored MAC address, as before. For anyone interested, here is attached the required patch; unfortunately a rebuild of the kernel is needed. 22-05.0-orangepizero-xradio_skupsy_20220520.patch

Confirmed on multiple devices here too. I can confirm that reverting to kernel 5.10.60 temporarily solves the issue; kernels above 5.15.25 have the same issue too. Changing or force the MAC address of the interface (i.e. with macchanger) doesn't solve the issue and breaks wifi functionality completely. There should be some bug in the kernel driver, but the statement above suggests that it may be more serious than the bare read of MAC address (from device firmware?). For applications where a static MAC address is preferred to assign a specific IP address by DHCP, I opted for statically assign that IP on the board network config.

For everyone interested.. I made several experiments, and I found out that the issue happens only if the wifi connection is teared down from the user. It doesn't happen if the connection is severed from AP side, for example. When the AP is restored the association is renegotiated almost immediately and works fine. Very, very strange. I'm pretty sure the problem is not in wpa_supplicant, because it works fine if I don't use the onboard wifi (for example using an USB wifi dongle); it must definitively be something wrong/missing with the 8189es driver Nevertheless, there are several quick workarounds. For example: don't disconnect from nmtui or wpa_cli, use ifdown instead.

Hello folks! I'm investigating an odd issue of the OPi R1 board, with the image Armbian_5.83_Orangepi-r1_Debian_stretch_next_4.19.38. With this version of software the board works fine, but apparently the wifi cannot reconnect after a disconnection (error: association request to the driver failed) The only workaround I found is to manually bring down the wifi interface and then back up; then the reconnect is almost immediate. I tried to disable the NetworkManager and now I'm using /etc/network/interfaces file to handle the connections but the problem still persists. I checked the issue with another R1 board and so I can exclude that the board is defective. I tried to reconfigure the board for using the latest kernel available (5.1.0) but the problem is still here. Is this a known problem/limit and/or has anyone experienced a similar issue or found any solution? Or at least point me to some direction to investigate further?