BPI-R3 multi_ap WDS issue (device crash)

The long story short:

I am facing an issue while using a BPI-R3 as WDS-AP with the 5 GHz radio. I tested with several devices (Archer Ax23, TL-WA1201, Archer C6) as WDS-STA and always the behavior is the same.

When I perform a speedtest through the WDS-STA the downstream test runs fine, but when the upstream test starts after 2 or 3 seconds the WDS link goes down and is lost. I manage to connect via SSH to the router but the load average quickly increases and the device becomes inaccessible, which difficults to me to take more information.

I have tested WDS bridges between the mentioned devices and it works well, so the issue seems to go about just the BRI-R3.

I will try to get more information via serial console, maybe it takes a little more to become unusable from that connection

The UCI configuration regarding the wireless part is:

wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.path='platform/soc/18000000.wifi'
wireless.radio0.channel='1'
wireless.radio0.band='2g'
wireless.radio0.htmode='HE20'
wireless.radio0.country='AR'
wireless.default_radio0=wifi-iface
wireless.default_radio0.device='radio0'
wireless.default_radio0.network='lan'
wireless.default_radio0.mode='ap'
wireless.default_radio0.ssid='Pablomagno'
wireless.default_radio0.encryption='psk2+ccmp'
wireless.default_radio0.key='testpassword'
wireless.default_radio0.ifname='bss0'
wireless.default_radio0.macaddr='ae:87:47:b2:dd:ce'
wireless.default_radio0.bss_transition='1'
wireless.default_radio0.multi_ap='2'
wireless.default_radio0.max_inactivity='40'
wireless.default_radio0.wps_pushbutton='1'
wireless.default_radio0.multi_ap_backhaul_ssid='SMBackhaulSSID_ae:87:47:b2:dd:d7'
wireless.default_radio0.multi_ap_backhaul_key='cCTgAIz3MydKFaLG'
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.path='platform/soc/18000000.wifi+1'
wireless.radio1.channel='36'
wireless.radio1.band='5g'
wireless.radio1.htmode='HE80'
wireless.radio1.country='AR'
wireless.default_radio1=wifi-iface
wireless.default_radio1.device='radio1'
wireless.default_radio1.network='lan'
wireless.default_radio1.mode='ap'
wireless.default_radio1.ssid='Pablomagno'
wireless.default_radio1.encryption='psk2+ccmp'
wireless.default_radio1.key='testpassword'
wireless.default_radio1.ifname='bss1'
wireless.default_radio1.macaddr='ae:87:47:b2:dd:cf'
wireless.default_radio1.bss_transition='1'
wireless.default_radio1.multi_ap='2'
wireless.default_radio1.max_inactivity='40'
wireless.default_radio1.wps_pushbutton='1'
wireless.default_radio1.multi_ap_backhaul_ssid='SMBackhaulSSID_ae:87:47:b2:dd:d7'
wireless.default_radio1.multi_ap_backhaul_key='cCTgAIz3MydKFaLG'
wireless.wifinet2G_2=wifi-iface
wireless.wifinet2G_2.device='radio0'
wireless.wifinet2G_2.mode='monitor'
wireless.wifinet5G_2=wifi-iface
wireless.wifinet5G_2.device='radio1'
wireless.wifinet5G_2.mode='ap'
wireless.wifinet5G_2.ssid='SMBackhaulSSID_ae:87:47:b2:dd:d7'
wireless.wifinet5G_2.encryption='psk2+ccmp'
wireless.wifinet5G_2.network='lan'
wireless.wifinet5G_2.key='cCTgAIz3MydKFaLG'
wireless.wifinet5G_2.ifname='bss2'
wireless.wifinet5G_2.macaddr='ae:87:47:b2:dd:d0'
wireless.wifinet5G_2.bss_transition='1'
wireless.wifinet5G_2.multi_ap='1'
wireless.wifinet5G_2.hidden='1'
wireless.wifinet5G_4=wifi-iface
wireless.wifinet5G_4.device='radio1'
wireless.wifinet5G_4.mode='monitor'

There we have a fronthaul SSID and a monitor interface in 2.4 GHz and a fronthaul SSID, backhaul SSID and monitor interface in 5 GHz (with multi_ap WPS configured and working well)

Anyone with issues like this regarding BPI-R3 and WDS? (multi_ap or not)

Thanks in advance.

This is most likely the power supply and it's a known problem with the BPI-R3. See this forum post: https://forum.banana-pi.org/t/bpi-r3-clean-power-supply-needed/16799

Thank you but this seems not to be the case, tested with serveral power sources and always is exactly the same. That post I also do not find a clear clue about anyone having exactly the same issue as I.

If the problem were noise, in what frequency range would it be expected? 50/60 Hz? Khz? MHz? I can measure with an oscilloscope and check if it there is something which makes sense.

Now I left it untouched after the issue occured and I noticed that after some minutes the load average goes down and the device recovers its function, it does not reboot.

With logread I see something that maybe is related with this...

Fri May 10 15:08:49 2024 kern.err kernel: [  115.635982] mt798x-wmac 18000000.wifi: Message 000026ed (seq 3) timeout
Fri May 10 15:09:04 2024 authpriv.info dropbear[4577]: Child connection from 192.168.0.43:40756
Fri May 10 15:09:04 2024 authpriv.notice dropbear[4577]: Password auth succeeded for 'root' from 192.168.0.43:40756
Fri May 10 15:09:10 2024 kern.err kernel: [  136.097639] mt798x-wmac 18000000.wifi: Message 00005aed (seq 4) timeout
Fri May 10 15:09:30 2024 kern.err kernel: [  156.560876] mt798x-wmac 18000000.wifi: Message 000026ed (seq 5) timeout
Fri May 10 15:09:51 2024 kern.err kernel: [  177.021837] mt798x-wmac 18000000.wifi: Message 000025ed (seq 6) timeout
Fri May 10 15:09:51 2024 kern.debug kernel: [  177.028500] ------------[ cut here ]------------
Fri May 10 15:09:51 2024 kern.warn kernel: [  177.033102] WARNING: CPU: 3 PID: 108 at ___ieee80211_stop_tx_ba_session+0x34c/0x3b0 [mac80211]
Fri May 10 15:09:51 2024 kern.debug kernel: [  177.041744] Modules linked in: pppoe ppp_async nft_fib_inet nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet ebtable_nat ebtable_filter ebtable_broute pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_counter nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7915e mt76_connac_lib mt76 mac80211 iptable_mangle iptable_filter ipt_REJECT ip_tables ebtables ebt_vlan ebt_stp ebt_redirect ebt_pkttype ebt_mark_m ebt_mark ebt_limit ebt_among ebt_802_3 cfg80211 xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt_LOG x_tables slhc sfp nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mdio_i2c libcrc32c crc_ccitt compat br_netfilter crypto_safexcel pwm_fan i2c_gpio i2c_algo_bit veth sha1_generic seqiv md5 des_generic libdes authencesn authenc
Fri May 10 15:09:51 2024 kern.debug kernel: [  177.041911]  leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd gpio_button_hotplug usbcore usb_common
Fri May 10 15:09:51 2024 kern.debug kernel: [  177.138130] CPU: 3 PID: 108 Comm: kworker/u8:2 Not tainted 5.15.150 #0
Fri May 10 15:09:51 2024 kern.debug kernel: [  177.144639] Hardware name: Bananapi BPI-R3 (DT)
Fri May 10 15:09:51 2024 kern.debug kernel: [  177.149153] Workqueue: phy0 ieee80211_ba_session_work [mac80211]
Fri May 10 15:09:51 2024 kern.debug kernel: [  177.155179] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
Fri May 10 15:09:51 2024 kern.debug kernel: [  177.162119] pc : ___ieee80211_stop_tx_ba_session+0x34c/0x3b0 [mac80211]
Fri May 10 15:09:51 2024 kern.debug kernel: [  177.168729] lr : ___ieee80211_stop_tx_ba_session+0x214/0x3b0 [mac80211]
Fri May 10 15:09:51 2024 kern.debug kernel: [  177.175337] sp : ffffffc0090d3c80
Fri May 10 15:09:51 2024 kern.debug kernel: [  177.178635] x29: ffffffc0090d3c80 x28: ffffffc008b8e000 x27: 0000000000000001
Fri May 10 15:09:51 2024 kern.debug kernel: [  177.185751] x26: ffffff8000b97300 x25: ffffff8003b40880 x24: ffffffc008b8e000
Fri May 10 15:09:51 2024 kern.debug kernel: [  177.192865] x23: ffffffc000a9fd78 x22: ffffff80054120e8 x21: 0000000000000001

Update: disabling the monitor mode interface the issue seems to stop to occur, but once I enable it for a second during an upload test, the crash happens inmediatly