I did that “apt install armbian-firmware-full” but after reboot dietpi-config still reports “WiFi : Not Found | [On] | Disconnected”.
On this first reboot the port that was eth0 before reboot became eth1, but that was just one reboot. I will try more reboots and hope that it has finally settled on being the current layout.
EDIT: Nope, the very next reboot eth0 and eth1 switched ports again.
Annoying. I will keep keeping both plugged in for now then.
I see now also the non-full package contains this firmware, just at a wrong path: Add bluetooth firmware for RTL8852*U · armbian/firmware@b36383c · GitHub
So this is now doubled in -full 
. Not sure whether the driver is able to find firmware at different paths, or whether some old kernel builds where looking at /lib/firmware/rtl8852bu_fw instead of /lib/firmware/rtl_bt/rtl8852bu_fw.bin
Interesting is what the Radxa dev said on the PR which added these:
The Wi-Fi part does not need firmware but Bluetooth does.
Also Armbian devs actually mention only Bluetooth in this regards: OrangePi 5 Plus + official Wi-Fi and bluetooth R6 (Realtek RTL8852BE-CG BE CPU) does not work - Orange Pi 5 Plus - Armbian Community Forums
And the firmware dir is named rtl_bt, also indicating Bluetooth only. Finally, that it worked for you before is quite a prove that this firmware is not required .
Hmm, so that device tree does not help, also at least indicates to be fore the AP6275P module, not necessarily for the R6/RTL8852BE one. Additional firmware is required for RTL8852BE Bluetooth, but not WiFi. It worked with legacy kernel, but not with vendor one.
For completeness, here the kernel driver:
legacy: linux-rockchip/drivers/net/wireless/rockchip_wlan/rtl8852bu at rk-5.10-rkr6 · armbian/linux-rockchip · GitHubI remember and indeed rtw88 now covers most if these chips: linux-rockchip/drivers/net/wireless/realtek/rtw88/Kconfig at 2ef3143a76574ff6093c736f7c346f68cc5489cc · armbian/linux-rockchip · GitHub
But not RTL8852 family. rtw89 covers two of them: linux-rockchip/drivers/net/wireless/realtek/rtw89/Kconfig at 2ef3143a76574ff6093c736f7c346f68cc5489cc · armbian/linux-rockchip · GitHub
Is the driver loaded?
lsmod
modprobe rtw89
dmesg | tail -5
ip l
Ahh, and here is the commit at Orange Pi kernel sources, which updates this particular driver to contain RTL8852BE: net: wireless: realtek: Sync rtw89 driver from linux6.2 · orangepi-xunlong/linux-orangepi@96b2d28 · GitHub
I hope Werner from Armbian reads my info about this in the linked topic. We can also add it as patch, but it is a huge patch for our own builds, but it is a huge patch, and of course all Armbian users benefit from having this in kernel sources directly: https://github.com/orangepi-xunlong/linux-orangepi/commit/96b2d2827a3f1e4719ebdfcac0b2108e8cbae932.patch
Unfortunately I became visually impaired in 2017 so I can’t help digging through sources, logs and lots of forums text nowadays.
But I ran the requested commands.
# lsmod
Module Size Used by
xt_nat 16384 55
veth 28672 0
nft_chain_nat 16384 27
xt_MASQUERADE 16384 14
nf_nat 36864 3 xt_nat,nft_chain_nat,xt_MASQUERADE
nf_conntrack_netlink 40960 0
br_netfilter 24576 0
bridge 237568 1 br_netfilter
stp 16384 1 bridge
llc 16384 2 bridge,stp
overlay 114688 16
binfmt_misc 20480 1
ip6t_REJECT 16384 1
nf_reject_ipv6 20480 1 ip6t_REJECT
xt_hl 16384 22
ip6_tables 28672 52
ip6t_rt 16384 3
ipt_REJECT 16384 1
nf_reject_ipv4 16384 1 ipt_REJECT
xt_LOG 16384 10
nf_log_syslog 20480 10
nft_limit 16384 13
goodix_ts 28672 0
pwm_fan 20480 0
xt_limit 16384 0
xt_addrtype 16384 6
panfrost 61440 0
drm_shmem_helper 20480 1 panfrost
xt_conntrack 16384 23
gpu_sched 32768 1 panfrost
joydev 24576 0
nf_conntrack 110592 5 xt_conntrack,nf_nat,xt_nat,nf_conntrack_netlink,xt_MASQUERADE
input_leds 16384 0
nf_defrag_ipv6 20480 1 nf_conntrack
nf_defrag_ipv4 16384 1 nf_conntrack
nft_compat 20480 195
nf_tables 192512 1544 nft_compat,nft_chain_nat,nft_limit
nfnetlink 20480 4 nft_compat,nf_conntrack_netlink,nf_tables
fuse 110592 1
dm_mod 106496 0
ip_tables 28672 8
ipv6 454656 229 bridge,br_netfilter,nf_reject_ipv6
r8169 73728 0
pwm_bl 16384 0
adc_keys 16384 0
This seems… problematic. ;-/
# modprobe rtw89
modprobe: FATAL: Module rtw89 not found in directory /lib/modules/6.1.43-vendor-rk35xx
next:
# dmesg | tail -5
[ 24.849414] br-c09cefb8452c: port 8(veth6e21160) entered blocking state
[ 24.849434] br-c09cefb8452c: port 8(veth6e21160) entered forwarding state
[ 24.880031] eth1: renamed from veth94dc5bc
[ 24.900444] br-ba8bee45a3fc: port 1(veth81b3afa) entered blocking state
[ 24.900482] br-ba8bee45a3fc: port 1(veth81b3afa) entered forwarding state
and finally:
# ip l
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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff
4: br-[REDACTED]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff
5: br-[REDACTED]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff
6: br-[REDACTED]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff
7: br-[REDACTED]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff
8: br-[REDACTED]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff
9: br-[REDACTED]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff
10: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff
12: veth[REDACTED]@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-6ea3a3dc9d88 state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff link-netnsid 2
14: veth[REDACTED]@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-c09cefb8452c state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff link-netnsid 1
16: veth[REDACTED]@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-863c1bd3450b state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff link-netnsid 7
18: veth[REDACTED]@if17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2043405788ba state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff link-netnsid 0
20: veth[REDACTED]@if19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-ba8bee45a3fc state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff link-netnsid 11
22: veth[REDACTED]@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-fe687a7987d9 state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff link-netnsid 6
24: veth[REDACTED]@if23: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-c09cefb8452c state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff link-netnsid 4
26: veth[REDACTED]@if25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-c09cefb8452c state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff link-netnsid 10
28: veth[REDACTED]@if27: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-c09cefb8452c state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff link-netnsid 3
30: veth[REDACTED]@if29: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-c09cefb8452c state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff link-netnsid 5
32: veth[REDACTED]@if31: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-c09cefb8452c state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff link-netnsid 8
34: veth[REDACTED]@if33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-c09cefb8452c state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff link-netnsid 9
36: veth[REDACTED]@if35: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-c09cefb8452c state UP mode DEFAULT group default
link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff link-netnsid 11
EDIT: Also, should I unmark " armbian-firmware-full" as manually installed and/or remove any of the files previously manually copied around on your request, to keep the system clean during further troubleshooting?
Would be annoying the cause is believed to be found but it turns out to depend on one of the previous steps and we forgot about it…
Ah, the module name would be rtw89_8852be. Interestingly, the driver sources are there: linux-rockchip/drivers/net/wireless/realtek/rtw89/rtw8852be.c at 2ef3143a76574ff6093c736f7c346f68cc5489cc · armbian/linux-rockchip · GitHub
But they are not compiled: linux-rockchip/drivers/net/wireless/realtek/rtw89/Kconfig at 2ef3143a76574ff6093c736f7c346f68cc5489cc · armbian/linux-rockchip · GitHub
The package does not contain it. Also the commit on Orange Pi sources did not add this file, but updated it, and updated Kconfig and Makefile to actually build it. So yeah, it all looks like we need to patch this driver update into our kernel build.
To revert the unnecessary steps we did:
apt install armbian-firmware
sed -i '/^user_overlays=/d' /boot/dietpiEnv.txt
rm /boot/overlay-user/m2-pcie-wifi.dtbo
Just to verify, I tried it anyway, because why not, but… nope:
# modprobe rtw89_8852be
modprobe: FATAL: Module rtw89_8852be not found in directory /lib/modules/6.1.43-vendor-rk35xx
Changes reverted as per your commands, then rebooted and everything looks as functional as before the reverting.
Thanks for looking into this.
New kernel build is ready:
cd /tmp
wget https://dietpi.com/downloads/binaries/testing/linux-{image,dtb}-vendor-rk35xx.deb
dpkg -i linux-{image,dtb}-vendor-rk35xx.deb
reboot
If it does not work OOTB, try to load the kernel module manually (I don’t know the mechanism which does this automatically when matching devices are detected):
modprobe rtw89_8852be
ls -l
Sorry for the delay, I was busy on May 1 and needed some rest the next day.
I installed the new kernel
# dpkg -i linux-{image,dtb}-vendor-rk35xx.deb
(Reading database ... 28295 files and directories currently installed.)
Preparing to unpack linux-image-vendor-rk35xx.deb ...
Armbian 'linux-image-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'prerm' starting.
Armbian 'linux-image-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'prerm' finishing.
Armbian 'linux-image-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'preinst' starting.
Armbian 'linux-image-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'preinst' finishing.
Unpacking linux-image-vendor-rk35xx (24.5.0-trunk) over (24.5.0-trunk) ...
Armbian 'linux-image-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'postrm' starting.
Removing obsolete initramfs images
Armbian 'linux-image-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'postrm' finishing.
Preparing to unpack linux-dtb-vendor-rk35xx.deb ...
Armbian 'linux-dtb-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'preinst' starting.
Armbian 'linux-dtb-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'preinst' finishing.
Unpacking linux-dtb-vendor-rk35xx (24.5.0-trunk) over (24.5.0-trunk) ...
Setting up linux-image-vendor-rk35xx (24.5.0-trunk) ...
Armbian 'linux-image-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'postinst' starting.
Removing obsolete initramfs images
update-initramfs: Generating /boot/initrd.img-6.1.43-vendor-rk35xx
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8402-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8105e-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for module r8169
update-initramfs: Converting to U-Boot format
Image Name: uInitrd
Created: Fri May 3 13:58:47 2024
Image Type: AArch64 Linux RAMDisk Image (gzip compressed)
Data Size: 7945123 Bytes = 7758.91 KiB = 7.58 MiB
Load Address: 00000000
Entry Point: 00000000
'/boot/uInitrd' -> 'uInitrd-6.1.43-vendor-rk35xx'
Armbian: update last-installed kernel symlink to 'Image'...
'/boot/Image' -> 'vmlinuz-6.1.43-vendor-rk35xx'
Armbian: Debian compat: linux-update-symlinks install 6.1.43-vendor-rk35xx boot/vmlinuz-6.1.43-vendor-rk35xx
Armbian 'linux-image-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'postinst' finishing.
Setting up linux-dtb-vendor-rk35xx (24.5.0-trunk) ...
Armbian 'linux-dtb-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'postinst' starting.
Armbian: DTB: symlinking /boot/dtb to /boot/dtb-6.1.43-vendor-rk35xx...
'dtb' -> 'dtb-6.1.43-vendor-rk35xx'
Armbian 'linux-dtb-vendor-rk35xx' for '6.1.43-vendor-rk35xx': 'postinst' finishing.
So now the machine has
# uname -a
Linux [REDACTED] 6.1.43-vendor-rk35xx #1 SMP Sat Apr 27 18:12:21 UTC 2024 aarch64 GNU/Linux
and although there were some warnings about “possible missing firmware”, it seems to be fine.
The interface wlan0 became available immediately (without manual modprobe) and it could be configured via dietpi-config.
Scanning for SSID in dietpi-config didn’t work, but after entering the desired SSID manually it got its IP-address via DHCP and pinging hosts on the Internet worked. That’s all I tested.
Unfortunately the wired ports eth0 and eth1 are still confused sometimes on reboot about which of the physical ports are which and the rare bug where the machine seems to get stuck on reboot just after having left the kernel still happened after installing the new kernel, so neither of the two issues I was personally hoping would have been fixed by the upgrade have been fixed in this version of the kernel.
Oh well. I’ll just still keep both ports plugged in and sometimes rarely go pull and reinsert the power cable when the LED (which I set to blink for “activity”) stops blinking after I requested a reboot so device is stuck.
Still thankful for the assistance looking into upgrading the kernel.
I have not tried bluetooth-functionality with the new kernel.
So far so good. Does iw work to scan for SSIDs?
iw wlan0 scan
We use iwlist wlan0 scan (the old deprecated wireless-tools), since there are cases with older WiFi adapters where iw scan hangs forever. iwlist however won’t work with WiFi 7 anymore at all. Pretty nasty that there is no sane way to automatically switch between both tools, aside of some nasty wrapper to have an iw timeout or so. But probably it is time to go the nasty route.
Both iw wlan0 scan and iwlist wlan0 scan lists networks and now dietpi-config does too.
Looking at the output I notice that there is a
ESSID:"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
in the list of available networks, which may have cause some software to be confused.
Using the WiFiScanner (WiFiScanner | F-Droid - Free and Open Source Android App Repository) on my phone I see a network with an empty (not hidden, empty) network name, so that’s probably that weird network. That seems like non-standard naming behavior. Not mine, not within my control.
So, anyway, it seems that’s actually all fine then.
Okay, so for now we can keep iwlist only then.
Not sure whether this weird SSID character pattern messes with the whiptail menu. When copy&pasting it from the forum into a manual whiptail menu, it works, but control characters might have been lost on the way.
This is the particular command we run:
iwlist wlan0 scan | sed -n '/^[[:blank:]]*ESSID:/s/^[[:blank:]]*ESSID:"\(.*\)"/\1/p'
We could actually use mawk now, to shorten the code a little 
:
iwlist wlan0 scan | mawk -F\" '/^[[:blank:]]*ESSID:/{print $2}'
Though, this would choke on " characters within the SSID 
.
Yeah, it does indeed.
Best we could do is to store any SSIDs with control characters (if those can really be detected via [[:cntrl:]] regex) internally and show some replacement in the menu. When the replacement entry is selected, we could store the original string in configs. But I am not sure whether the control characters survive read/write from/to config files, and are valid for an SSID at all .
One could just on detecting presence of such, being unprintable characters anyway (and I still believe non-standard, probably just put there to actually achieve non-standard effects like breaking other people’s devices) just replace that network’s name in the list entirely with something like [INVALID NAME] and move on to the valid ones.
That way if it would be the DietPi-user that set their ESSID to something with unprintable characters, they at least would get a hint that maybe they should consider… not doing that.
But again, seems to me as extremely unusual so extremely low priority.
Could you test this version?
curl -sSfo /boot/dietpi/func/dietpi-wifidb 'https://raw.githubusercontent.com/MichaIng/DietPi/ssid/dietpi/func/dietpi-wifidb'
It checks the string for control characters, and in case adds a line with empty value but “INVALID SSID” at the right side. So that one cannot be selected: The menu just reloads when lines with empty value (left side text) are selected. Let’s see whether the SSID contains something which matches the [[:cntrl:]] characters class.
You mean does not seem to have worked?
Btw, there seem to be whichever use cases to use such SSID, and generally it is not invalid: wireless networking - Create network with SSID containing null characters (\0) - Super User
However, until we can handle them, we should avoid them. Okay let’s see what pattern it matches:
iwlist wlan0 scan | grep 'ESSID:.*[[:cntrl:]].*"'
iwlist wlan0 scan | grep 'ESSID:.*\\x00.*"'
iwlist wlan0 scan | grep -P 'ESSID:.*\x00.*"'
A different question how to match those in bash conditionals [[ $var =~ ... ]]. There is this $'...' POSIX string syntax, but AFAIK this can only be used to match a specific character, no range/pattern.
Yes, sorry, that’s what I meant.
I need rest, it seems. I’ll do that after this post.
The first and third one matched nothing, gave no output.
The second one however:
# iwlist wlan0 scan | grep 'ESSID:.*\\x00.*"'
ESSID:"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
ESSID:"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
Interesting, so this pattern seems to be present literally. Strangely, testing this with a manual G_WHIP_MENU did not cause any issues, like those grey bars you have . Still possible there there is something leading or trailing which causes issues.
Oh, 
The grey is my redaction, as in my earlier screenshots previously in this thread. Some SSIDs do contain personally identifiable information, including location names.
I did not put back the original “dietpi-wifidb” file yet. Maybe that influenced the grep pattern matching?
Ah, so are there any visual issues then? Since the SSID is long, it exceeds the max menu width a little, which looks funny, but otherwise? Are the other SSIDs fully visible, or is something cut at the left side?
dietpi-wifidb has no effect on the low level UNIX system tool iw 
.