Thank you all for your input. And a big thank to @djurny I will double check if end user can add static route on their Windows machine or whatever PC1 is. route add 10.10.10.2 mask 255.255.255.255 192.168.100.101 As this solution appears to work. Alternative way is bridging the NICs however Device1 requires separate subnet from NIC1.... Thank you again.

Summary Update: A Look At Pure Ubuntu (no Armbian) --> The bug was there, then it was not! Initial Observation: Debian 13 (Trixie) The Bug Is Present Operating System: Debian GNU/Linux 13 KDE Plasma Version: 6.3.6 KDE Frameworks Version: 6.13.0 Qt Version: 6.8.2 Kernel Version: 6.16.4-edge-rockchip64 (64-bit) Graphics Platform: Wayland Ubuntu 25.04 The Bug Is Present Distributor ID: Ubuntu Description: Ubuntu 25.04 Release: 25.04 Codename: plucky Operating System: Ubuntu 12 KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.3 Kernel Version: 6.16.0-17-generic (64-bit) Graphics Platform: Wayland Ubuntu 25.10 The Bug Is Gone! Distributor ID: Ubuntu Description: Ubuntu Questing Quokka (development branch) Release: 25.10 Codename: questing Operating System: Ubuntu 13 KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.17.0 Qt Version: 6.8.3 Kernel Version: 6.16.0-17-generic (64-bit) Graphics Platform: Wayland Conclusion The bug was in Ubuntu. Then it wasn't. So the answers to how to fix it are likely in the changes made in or by Ubuntu.

I have a question regarding the configuration of the /etc/asound.conf file... are there any changes in the new kernel that prevent this from happening? I've noticed that my USB audio card no longer loses its settings and its position doesn't change. However, to be sure, I tried editing the /etc/asound.conf file... but it turns out to be impossible 🙂 That is, after saving the settings in /etc/asound.conf... ALSA doesn't work! 🙂 Moreover, the blocking for certain selected devices doesn't work either. In my case, the blocking is: HDMI Audio... in the file: /etc/modprobe.d/blacklist.conf blacklist sun9i_hdmi_audio blacklist snd_soc_simple_card Are these changes related to the detection/blocking, etc., of block devices in Linux?

just 2 cents : if PC1 can access "Rocky Liinux" , if what you need is to access a particular UDP or TCP port on Device 1 10.10.10.2, you can try port forwarding normally done with iptables, nftables, ufw etc also called NAT (netowork address translation) e.g. https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)#Destination_NAT this needs to be done on "Rocky Linux"

Yes. This is an example of a rk3588 based board of mine: overlay_prefix=rockchip-rk3588 overlays=panthor-gpu opp-oc-24ghz The overlay names come from /boot/dtb/*/ find an overlay matching your soc and needs and enable by putting its name to overlays=. Then reboot. Having a serial console to read uboot logs can show if it has been loaded properly or in case it did not why.