loeriver

Meanwhile I did replace systemd-resolved on Trixie with resolvconf. Unfortunately, although the configuration now is (to my knowledge) mostly identical to the working Bookworm AP, it still does not work. When I connect a Debian system to both APs, the output of "ip r" is identical. Also the output of "dig <some server>". But "ping" works only partially for the Trixie AP: I get only a ping answer for the AP address. Same for traceroute. What I did observe using tcpdump: ssh communication with the Bookworm system gives "ack/seq pairs": 23:56:26.276869 IP 172.24.1.77.54840 > 192.168.178.29.22: Flags [.], ack 18029, win 537, options [nop,nop,TS val 1656092742 ecr 742514735], length 0 23:56:26.278437 IP 192.168.178.29.22 > 172.24.1.77.54840: Flags [P.], seq 18029:18105, ack 8352, win 344, options [nop,nop,TS val 742514737 ecr 1656092742], length 76 Whereas the same with the Trixie system gives (apparently much longer) sequences of only "seq" entries: 23:56:26.962828 IP 172.24.1.77.54840 > 192.168.178.29.22: Flags [P.], seq 9612:9648, ack 19365, win 537, options [nop,nop,TS val 1656093428 ecr 742515405], length 36 23:56:26.964613 IP 192.168.178.29.22 > 172.24.1.77.54840: Flags [P.], seq 19365:19401, ack 9648, win 344, options [nop,nop,TS val 742515423 ecr 1656093428], length 36 23:56:26.982677 IP 172.24.1.77.54840 > 192.168.178.29.22: Flags [P.], seq 9648:9684, ack 19401, win 537, options [nop,nop,TS val 1656093447 ecr 742515423], length 36 23:56:26.984461 IP 192.168.178.29.22 > 172.24.1.77.54840: Flags [P.], seq 19401:19437, ack 9684, win 344, options [nop,nop,TS val 742515443 ecr 1656093447], length 36 23:56:27.001390 IP 172.24.1.77.54840 > 192.168.178.29.22: Flags [P.], seq 9684:9720, ack 19437, win 537, options [nop,nop,TS val 1656093466 ecr 742515443], length 36 I guess I get some SD cards now and install different clean images to start from ...

Now I attacked the issue from the clients side and tried to connect from a "real" (Debian) system. Client Syslog output on connect looks quite comparable, but on the "failing" AP I seem to have a DNS issue: ping and traceroute do not work from the client in that case (and work when I connect to the "Bookworm AP"). From the AP computers I can alway resolve hostnames. So I will investigate this further (on Bookworm the resolveconf service is used, on Trixie systemd-resolved: so I assume an issue in the DNS setup of dnsmasq). I will not follow the "RADIUS" path anymore (for now), the brcmf_psm_watchdog_notify issue will also remain untouched (it is with me for a long time on the BPiPro now).

Now I have tried to bring my non-working Trixie setup as near as possible to my working Bookworm setup (both BananaPi Pro boards) (and: no bridging stuff here!): -I replaced systemd-networkd with NetworkManager on Trixie -I restricted NM to handling of end0 (wlan0 as "unmanaged"), set up everything "the old way" as it is working on Bookworm (manual hostapd, dnsmasq, iptables) And now I try to connect from my mobile phone to both APs: Bookworm is okay as always, Trixie says "connect w/o internet" (although the very first time before rebooting it connected w/ Internet). In the extended dnsmasq log I see in both cases lots of connection names, but anyway the Trixie AP claims to have "no internet". The only visible difference is the log output for hostapd (both v2.10): in the failing case the following lines are printed for every connection, whereas in the working case these are not there: 2026-07-14T19:15:41.505822+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e IEEE 802.11: associated 2026-07-14T19:15:41.541156+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e RADIUS: starting accounting session 0F32AA180BFF0C2C 2026-07-14T19:15:41.542161+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e WPA: pairwise key handshake completed (RSN) ....(many lines of log output from dnsmasq) 2026-07-14T19:15:58.724493+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e IEEE 802.11: disassociated I have no clue what activates this RADIUS stuff and why there is this associated / disassociated pair (or why it is not there in the Bookworm case).

Many thanks for your investigations! SD card issues are solved, I obviously stopped the system during a write operation - after a shutdown (and card check with an PCs adapter) the errors are gone. But this had no impact. What I did for comparison: I applied the same semi-manual netplan / networkd / hostapd setup sequence to an OrangePiZero, also trixie ( v26.8 rolling for Orange Pi Zero running Armbian Linux 6.18.37-current-sunxi). And guess what: this works without a hiccup! So I looked into the syslog output when connecting. This is the output for the OPi (success!): 2026-07-07T20:47:35.333876+02:00 orangepizero hostapd: wlan0: STA ee:79:bc:4f:11:45 IEEE 802.11: authenticated 2026-07-07T20:47:35.336530+02:00 orangepizero hostapd: wlan0: STA ee:79:bc:4f:11:45 IEEE 802.11: associated (aid 1) 2026-07-07T20:47:35.406476+02:00 orangepizero hostapd: wlan0: STA ee:79:bc:4f:11:45 RADIUS: starting accounting session 01344FB459DCA3B1 2026-07-07T20:47:35.407484+02:00 orangepizero hostapd: wlan0: STA ee:79:bc:4f:11:45 WPA: pairwise key handshake completed (RSN) 2026-07-07T20:47:35.409156+02:00 orangepizero kernel: ieee80211 phy0: CCMP_PAIRWISE keylen=16! And this is the output for the failing BPi: 2026-07-06T17:54:46.957014+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e IEEE 802.11: associated 2026-07-06T17:54:46.983182+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e RADIUS: starting accounting session 9B014BB4D748D33B 2026-07-06T17:54:46.984065+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e WPA: pairwise key handshake completed (RSN) 2026-07-06T17:55:28.848201+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e IEEE 802.11: disassociated or: (worst case) 2026-07-07T16:52:15.236724+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e IEEE 802.11: associated 2026-07-07T16:52:15.270595+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e RADIUS: starting accounting session E501E4B1A6220EF1 2026-07-07T16:52:15.271648+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e WPA: pairwise key handshake completed (RSN) 2026-07-07T16:52:30.104160+02:00 bananapipro kernel: ieee80211 phy0: brcmf_psm_watchdog_notify: PSM's watchdog has fired! 2026-07-07T16:55:07.185663+02:00 bananapipro kernel: brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout 2026-07-07T16:55:07.185794+02:00 bananapipro kernel: ieee80211 phy0: brcmf_cfg80211_get_channel: chanspec failed (-110) 2026-07-07T16:55:09.745805+02:00 bananapipro kernel: brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout 2026-07-07T16:55:09.749180+02:00 bananapipro kernel: ieee80211 phy0: brcmf_cfg80211_get_tx_power: error (-110) 2026-07-07T16:57:18.001649+02:00 bananapipro kernel: brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout 2026-07-07T16:57:20.561670+02:00 bananapipro kernel: ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 2026-07-07T16:57:20.562221+02:00 bananapipro kernel: ieee80211 phy0: brcmf_cfg80211_get_station: GET STA INFO failed, -110 2026-07-07T16:58:23.281661+02:00 bananapipro kernel: ieee80211 phy0: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 2026-07-07T16:58:23.282246+02:00 bananapipro kernel: ieee80211 phy0: brcmf_cfg80211_get_channel: chanspec failed (-110) .... (more errors) The ip link/ ip route is identical, for the OPi also the networkctl output is clean: root@orangepizero:/home/thomas/work# networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 end0 ether enslaved configured 3 wlan0 wlan enslaved configured 5 br0 bridge routable configured 4 links listed. I also started to compare the log outputs for the start of hostapd, many things look equal / "similar" (maybe due to different underlaying hardware). I could provide the 2 (streamlined) logs, here only the most obvious deltas: nl80211: flush -> DEL_STATION wlan0 (all) --> nl80211: Station flush failed: ret=-14 (Bad address) (BPi) <none> (OPi) <TX queue cmds OPi> nl80211: TX queue param set: queue=0 aifs=1 cw_min=3 cw_max=7 burst_time=15 --> res=0 nl80211: TX queue param set: queue=1 aifs=1 cw_min=7 cw_max=15 burst_time=30 --> res=0 nl80211: TX queue param set: queue=2 aifs=3 cw_min=15 cw_max=63 burst_time=0 --> res=0 nl80211: TX queue param set: queue=3 aifs=7 cw_min=15 cw_max=1023 burst_time=0 --> res=0 <TX queue cmds BPi> nl80211: TX queue param set: queue=0 aifs=1 cw_min=3 cw_max=7 burst_time=15 --> res=-95 Failed to set TX queue parameters for queue 0. nl80211: TX queue param set: queue=1 aifs=1 cw_min=7 cw_max=15 burst_time=30 --> res=-95 Failed to set TX queue parameters for queue 1. nl80211: TX queue param set: queue=2 aifs=3 cw_min=15 cw_max=63 burst_time=0 --> res=-95 Failed to set TX queue parameters for queue 2. nl80211: TX queue param set: queue=3 aifs=7 cw_min=15 cw_max=1023 burst_time=0 --> res=-95 Failed to set TX queue parameters for queue 3. Question is, if I have to give up on the hardware or try a SW workaround (as my old solution running on BPiPro Bookworm / NM: wifi set to umanaged and using a hand-made hostapd / dnsmasq / iptables solution - will this work for Trixie? Do not know.)

Well, netplan is the advertised / provided solution for Armbian. So when you look into /etc/systemd/network you find a readme from armbian pointing you to /etc/netplan. I think what netplan does is generating the following files for systemd-networkd under /run/systemd/network: 10-netplan-end0.network: [Match] Name=end0 [Link] MACAddress=02:cd:08:83:3c:f3 [Network] LinkLocalAddressing=no Bridge=br0 10-netplan-wlan0.network [Match] Name=wlan0 [Network] LinkLocalAddressing=no Bridge=br0 10-netplan-br0.network [Match] Name=br0 [Network] LinkLocalAddressing=ipv6 Address=192.168.178.29/24 DNS=9.9.9.9 DNS=1.1.1.1 ConfigureWithoutCarrier=yes [Route] Destination=0.0.0.0/0 Gateway=192.168.178.1 Metric=200 10-netplan-br0.netdev [NetDev] Name=br0 Kind=bridge And this is the ip output: ip route: default via 192.168.178.1 dev br0 proto static metric 200 192.168.178.0/24 dev br0 proto kernel scope link src 192.168.178.29 ip link: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP mode DEFAULT group default qlen 1000 link/ether 02:cd:08:83:3c:f3 brd ff:ff:ff:ff:ff:ff altname enx02cd08833cf3 3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether a2:67:ed:53:cb:f1 brd ff:ff:ff:ff:ff:ff 4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000 link/ether e0:76:d0:03:53:bc brd ff:ff:ff:ff:ff:ff altname wlxe076d00353bc

I tried to build an bridged AP so that I can reach the Internet from a WiFi net spawned from the BananaPiPro. By this I followed the procedure from armbian-config (config.network.sh). After install the AP is shown in the login screen: WiFi AP: SSID: (BPi), channel 7 (2442 MHz), width: 20 MHz, center1: 2442 MHz When I try to connect from my mobile phone it either says "connecting without Internet". The output in syslog is then: 026-07-06T12:35:02.645970+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e IEEE 802.11: associated 2026-07-06T12:35:02.690671+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e RADIUS: starting accounting session 500A81EDD1715454 2026-07-06T12:35:02.691497+02:00 bananapipro hostapd: wlan0: STA 22:50:7b:ac:e3:2e WPA: pairwise key handshake completed (RSN) Ort otherwise the phone just says "cannot connect". My netplan file is as follows: network: version: 2 renderer: networkd ethernets: end0: dhcp4: false dhcp6: false macaddress: "02:cd:08:83:3c:f3" wlan0: dhcp4: false dhcp6: false bridges: br0: addresses: - "192.168.178.29/24" nameservers: addresses: - 9.9.9.9 - 1.1.1.1 interfaces: - wlan0 - end0 routes: - metric: 200 to: default via: "192.168.178.1" The hostapd.conf is: interface=wlan0 driver=nl80211 ssid=BPi hw_mode=g channel=7 wmm_enabled=0 macaddr_acl=0 auth_algs=1 ignore_broadcast_ssid=0 wpa=2 wpa_passphrase=secret wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP rsn_pairwise=CCMP ctrl_interface=/var/run/hostapd ctrl_interface_group=0 ieee80211n=1 ht_capab=[DSSS_CK-40][HT20+] preamble=1 bridge=br0 The output of network list is: root@bananapipro:/etc/hostapd# networkctl list IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 end0 ether enslaved configured 3 br0 bridge routable configured 4 wlan0 wlan enslaved failed Does anybody have an idea where to look further for a solution? As I have an AP running on my other BananaPiPro (Bookworm CLI / Networkmanager, manual config, not bridged) it cannot be a complete HW limitation, I think.

Hi, just to give a maybe final feedback on this topic: Although it is not a really satisfying solution, I decided to switch off the sysrq functionality by setting kernel.sysrq=0 in /etc/sysctl.conf. This was 1 month ago and there were no sysrq events in my logs since then. So for now this is a "good enough" solution for me. Thank you all for your support, I learned again a lot ...

Hi, that's me again after a recent very bad sysrq incident on my system (I was away for a couple of days and the system went down for this time). I count > 5000 "sysrq: HELP" messages this time, 77 requests for loglevel changes (to 0, 4 or 8), 9 "show regs" requests, 1 "show state" and 4 "dump ftrace buffer" request. All this during 30 mins. The UART / USB converter was connected to ttyS0, but the PC on the other end was off. But I shall add that I also have connected the status output line of my UPS to ttyS1 (this is an "UPSPACK_V3" board that watches the 5V input and has a Li polymer battery connected). Could it also be that this system sends spurious BREAK commands that issue a SysRq event? And if yes: Is there a simple way to watch this interface? Maybe by temporarily logging the UPS board's UART Tx? Greetings.

Thank you - I should have checked w/ df. The reason is that /var/log is mapped to /dev/zram1 which is 47M for my system and auditd.conf requested space_left=75 (MiB, that is). I changed this to space_left=25% and admin_space_left=5%. No it starts to log something at least.

Hi and thank you for the advice. The USB end of the dongle goes to my desktop PC. I compared the time stamps of the last issue and found that the PC was actually switched off during the last issue, having been switched on 10 minutes after the last sysrq log entry. So for the moment I will watch the findings of auditd, although the startup msgs from yesterday looked somewhat suspicious (?): 2025-06-23T18:23:09.799581+02:00 bananapipro2 systemd[1]: Starting auditd.service - Security Auditing Service... 2025-06-23T18:23:09.910646+02:00 bananapipro2 auditd[18408]: Audit daemon is low on disk space for logging 2025-06-23T18:23:09.911684+02:00 bananapipro2 auditd[18408]: Audit daemon is suspending logging due to low disk space. 2025-06-23T18:23:09.912308+02:00 bananapipro2 auditd[18408]: No plugins found, not dispatching events 2025-06-23T18:23:09.917468+02:00 bananapipro2 auditd[18408]: Init complete, auditd 3.0.9 listening for events (startup state enable) 2025-06-23T18:23:10.181350+02:00 bananapipro2 systemd[1]: Started auditd.service - Security Auditing Service. Greetings.

Thank you for this very helpful hint. I have installed auditd, I thought I have to systemctl (start, enable) auditd also to have it watching: but this seems to have been done by the install cmd already, as it is running. As I saw a burst of 7225 (!) sysrq messages in the log for 2025-06-18, between 08:55 and 09:50 again I am rather nervous about this topic. Since then no new messages again. Mysterious ... Greetings.

Hi, thank you for your comments, at least I learned about the SysRq sequence this way. I actually have no clue which process should send this sequence, an hardware issue of the RX line seems also unlikely to me (very short wire to the RS232-USB converter). The only additional observations: -it is a rare event, 24x7 system, most recent events: Jun 9th: at the end of a shutdown sequence Jun, 5th: no obviously related entries in syslog before it May, 28th: no obviously related entries in syslog before it May, 24th: at the end of a shutdown sequence May, 23rd: at the end of a shutdown sequence May 22nd: at the end of a shutdown sequence -it always occurs in pairs, timestamps separated by some µs, e.g. 16:50:49.191219 and 16:50:49.191355 Meanwhile on v25.5.1 for Banana Pi Pro running Armbian Linux 6.12.30-current-sunxi. I guess I will have to live with this effect, which is not harmful as long as the system continues to run. Greetings.

From time to time I see a message like this in my log files: 2025-06-05T11:29:33.367636+02:00 bananapipro2 kernel: [934985.549250] sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w) dump-ftrace-buffer(z) replay-kernel-logs(R) The system continues to work (although I remember that it stooped at this point in older releases). Is there any action required? I am afraid that this could stop my system which is running unattended for longer periods usually. I am running v25.2.2 for Banana Pi Pro running Armbian Linux 6.12.20-current-sunxi.

When using armbian-config to select an overlay ("DTO001")e.g. for uart2, one is offered the full names w/ overlay prefix, e.g. sun7i-a20-uart2. The system adds this to armbianEnv.txt: overlays=sun7i-a20-uart2 But it has also the line overlay_prefix=sun7i-a20 In the end, uart2 is not activated (no output from /dev/ttyS1) - after changing the overlay line to overlays=uart2, I can read from /dev/ttyS1. System is Armbian 25.2.2 stable (bookeworm), Armbian Linux 6.12.20-current-sunxi.

I updated my Armbian on another board, saw the same brcm error an generated the required data, upload is here: https://paste.armbian.de/togofunode

Hi, unfortunately something seems not to work with armbianmonitor for me. I entered the above line as sudo and got this: <PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u System diagnosis information will now be uploaded to gzip: /var/log/armbian-hardware-monitor.log.1.gz: No such file or directory <!doctype html> <html lang=en> <head> <meta charset=utf-8> <title>&nbsp;</title> </head> <style> body { font-family: monospace; margin: 2em; } </style> <body> <p>ix.io is taking a break &#127867;</p> <img src="/underconstruction.gif" width="200px"> </body> </html> Please post the URL in the forum where you've been asked for. >

I am running a headless Bananapipro server that acts as an AP. Recently I found that its WiFi net was gone. In the log I found a crash of brcm: Dec 19 02:40:14 localhost kernel: [3919907.052132] ieee80211 phy0: brcmf_fw_crashed: Firmware has halted or crashed Dec 19 02:40:15 localhost kernel: [3919908.004319] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do. Dec 19 02:40:15 localhost kernel: [3919908.004360] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do. Dec 19 02:40:15 localhost kernel: [3919908.004372] ieee80211 phy0: brcmf_cfg80211_stop_ap: SET SSID error (-5) Dec 19 02:40:15 localhost kernel: [3919908.004388] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do. Dec 19 02:40:15 localhost kernel: [3919908.004399] ieee80211 phy0: brcmf_cfg80211_stop_ap: BRCMF_C_DOWN error -5 Dec 19 02:40:15 localhost kernel: [3919908.004411] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do. Dec 19 02:40:15 localhost kernel: [3919908.004422] ieee80211 phy0: brcmf_cfg80211_stop_ap: setting AP mode failed -5 Dec 19 02:40:15 localhost kernel: [3919908.004435] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do. Dec 19 02:40:15 localhost kernel: [3919908.004446] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do. Dec 19 02:40:15 localhost kernel: [3919908.206422] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1 Dec 19 02:40:15 localhost kernel: [3919908.206849] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43362-sdio.lemaker,bananapro.bin failed with error -2 Dec 19 02:40:15 localhost kernel: [3919908.206883] brcmfmac mmc1:0001:1: Falling back to sysfs fallback for: brcm/brcmfmac43362-sdio.lemaker,bananapro.bin Dec 19 02:40:15 localhost kernel: [3919908.274976] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43362-sdio.clm_blob failed with error -2 Dec 19 02:40:15 localhost kernel: [3919908.275024] brcmfmac mmc1:0001:1: Falling back to sysfs fallback for: brcm/brcmfmac43362-sdio.clm_blob Dec 19 02:40:15 localhost kernel: [3919908.537722] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available Dec 19 02:40:15 localhost kernel: [3919908.537759] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2) Dec 19 02:40:15 localhost kernel: [3919908.538389] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43362/1 wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d Dec 19 02:40:15 localhost NetworkManager[1088]: <info> [1734572415.8104] rfkill1: found Wi-Fi radio killswitch (at /sys/devices/platform/soc/1c12000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/ieee80211/phy1/rfkill1) (driver brcmfmac) WiFi could be re-activated by restarting the system. I shall also note that there are at least once a day messages like this in the log: Dec 19 22:36:32 localhost kernel: [20143.706800] ieee80211 phy0: brcmf_psm_watchdog_notify: PSM's watchdog has fired! The system is: uname -a Linux bananapipro2 6.6.44-current-sunxi #1 SMP Sat Aug 3 06:54:42 UTC 2024 armv7l GNU/Linux Are there any hints how to proceed with this issue? Many thanks, Thomas