Good that your bpi appears to be stable. My did hang again, no reaction on serial console, no reaction on IP networking. So I enabled the watchdog, uncommented the 'ping 192.168.1.1 line' and made it ping 192.168.1.100 and temporarily added that address to another computer: ip addr add dev br0 192.168.1.100/24 Then removing it: ip addr del dev br0 192.168.1.100/24 and after a minute or so: [ 263.929336] systemd-journald[236]: Received SIGTERM from PID 1071 (watchdog). [ 265.185973] systemd[1]: systemd 257.13-1~deb13u1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -BTF -XKBCOMMON -UTMP +SYSVINIT +LIBARCHIVE) [ 265.221538] systemd[1]: Detected architecture arm. [ 269.100327] systemd[1]: Failed to fork off sandboxing environment for executing generators: Protocol error [!!!!!!] Failed to start up manager. [ 269.146571] systemd[1]: Freezing execution. This looks like HW watchdog does not work. Same trick on NanoPi-NEO, so also sunxi kernel although 7.0.12-edge-sunxi, it resets. So appears to work although no proof that it is HW reset. I have not checked live dmesg or so, just noticed it went offline and came back later when I also added that .100 IP address again.

If you use and Armbian image with kernel '6.1.115-vendor-rk35xx' (note there are many builds over time, all same name, but you need to look in config-6.1.115-vendor-rk35xx and maybe also consider the gcc compiler version to have RKMPP based method working. I mean the API is there, you need a special ffmpeg (from jellyfin for example to use it) in order to use RKMPP based decoding and encoding in HW. That is just CLI, server use-case, works on RK3568 and RK3588. RK3576 should have the same speed/ASIC blocks as RK3588 AFAIK, but check yourself. It can do 5x realtime speed 1080p50 HEVC to H264. mpv 'uses open and agreed standards' and RKMPP is not. Also Android is completely different. Same is Windows or Apple iOS. Those are implemented by commercial/paid developers. In fact it is worse, ffmpeg open-source developers have concluded already long time ago the Rockchip downstream kernel code was copied and violates licenses. (Rockchip copied code and put their names in it.). So since a few months, ffmpeg developers requested github to remove access and that happened. So following GPL licensing, that 6.1.115 kernel is essentially illegal. How you want to deal with that is up to you. It is like it is. Anyway, 6.1.x downstream is getting old and might contain several unpatched security holes. So over time the 'problem' will solve itself as people won't trust it anymore despite being able to use every HW block in RK35xx. As already said, decoding generally is implemented as part on mainline kernel, you just need matching latest userspace. Encoding is much more complex. If you want that, only Intel/AMD is more or less viable option. Like N100, so in cheap miniPCs, certainly considering high RAM prices, is just a way better option. Plays all HW accelerated in FireFox (and mpv as well). Does also VP9 encoding for example, is a royalty free codec, so you won't see this 2 decades old patents issues for H264 and HEVC. Also note AV1 HW decoding was the first to be available in mainline kernel for RK3588. There is just not much content I think. And HW AV1 encoding is another level of new silicon, is not really an option to do in software.

Hi @Marus Gradinaru, May be this might interest you.

# cat /etc/NetworkManager/system-connections/br0.nmconnection [connection] id=br0 uuid=75d54cd2-cdfe-4621-ab45-0bddf3ab4e6c type=bridge interface-name=br0 zone=trusted [ethernet] cloned-mac-address=my eth0 mac address [ipv4] method=auto [ipv6] addr-gen-mode=default method=ignore # cat /etc/NetworkManager/system-connections/eth0-br0_slave.nmconnection [connection] id=eth0-br0_slave uuid=31645756-5c39-4184-a0c2-337ae09422ec type=ethernet interface-name=eth0 master=75d54cd2-cdfe-4621-ab45-0bddf3ab4e6c slave-type=bridge # cat /etc/NetworkManager/system-connections/wlan0-br0_slave.nmconnection [connection] id=wlan0-br0_slave uuid=4ff7f9f2-056e-4836-9bc7-0e77d98a989c type=wifi interface-name=wlan0 master=75d54cd2-cdfe-4621-ab45-0bddf3ab4e6c slave-type=bridge [wifi] band=bg channel=1 mode=ap ssid=mywifissid [wifi-security] key-mgmt=wpa-psk proto=rsn; psk=mypassword template, stripped, optimized, cleaned, untested

I would not give up on the BPiPro just because this networking stack/tool issues. As I indicated, a bridged WiFi AP works fine with NetworkManager. Armbian images are there to get you started very easily, even without Linux know-how. But it still is Linux, open-source, all DIY and no company you can manage to blame (try to find the engineer(s) who designed the SBC ... ). I know the majority of SBC users throws away working older installations and then get stuck with some new pre-installed image. You can instead just dist-upgrade in-place Netplan is from Canonical and there to uniform Ubuntu so NM and systemd-networkd can be used. Debian does not need netplan, there is no dependency on NM nor systemd-networkd. Now look at this: A script from Armbian does netplan yaml that does .netdev/.network files or .nmconnection files. As long as it works, fine. But 3 layers, from math permutation you can know that means many more potential error cases. So you want to discard HW because networking config tooling has become too complex? I forgot to power off the RPi3b+ before night and now in the morning the internet on the smartphone still works (via that AP). A simple reboot via serial console and short flip to 4G but then back to connected to the AP. BUT, the wlan0 again shows as 'failed'. So it seems a timing issue or so or just the status reporting is the issue. Also Android normally simply disconnects on PHY/MAC layer if no public routing ('internet'). That might happen easily after reboots or so or just without various timeouts. Note I have disabled systemd-networkd-wait-online.service else always 3 minutes waiting at reboot. You can also specify how and what to wait for, but needs reading docs. Also note that OS is not vanilla Debian aarch64, but from RPL, there is many changed packages, especially also in the network domain. And RPi3 has USB connected networking, not on the SoC like most other SBC's, this is also an issue I discovered. I see for another RPi3: @/raspi4/latest/etc/NetworkManager/system-connections -rw------- 1 root root 259 Jan 21 16:16 br0.nmconnection -rw------- 1 root root 217 Jan 21 16:16 eth0-br0_slave.nmconnection -rw------- 1 root root 312 Jan 22 10:44 wlan0-br0_slave.nmconnection Is still RPiOS arm64 bookworm, but with some hacks to prevent netplan and cloud-init disturbing things and wasting time, it also works with RPiOS Trixie. Certainly without tricks on standard Debian Trixie as I simply copy those 3 files to and from old AMD fanless computer etc that also has WiFi onboard. You need to make sure you stop and start NM at the proper moments and also make sure no UUID doubles or orphans. Should be fine when new, not yet booted image.