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…
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [30 April 2024 20:57 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/24 "2024-04-30T20:57:14Z")
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](https://github.com/armbian/linux-rockchip/blob/2ef3143a76574ff6093c736f7c346f68cc5489cc/drivers/net/wireless/realtek/rtw89/rtw8852be.c)
But they are not compiled: [linux-rockchip/drivers/net/wireless/realtek/rtw89/Kconfig at 2ef3143a76574ff6093c736f7c346f68cc5489cc · armbian/linux-rockchip · GitHub](https://github.com/armbian/linux-rockchip/blob/2ef3143a76574ff6093c736f7c346f68cc5489cc/drivers/net/wireless/realtek/rtw89/Kconfig)
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:
```sh
apt install armbian-firmware
sed -i '/^user_overlays=/d' /boot/dietpiEnv.txt
rm /boot/overlay-user/m2-pcie-wifi.dtbo
```
---
### Author:  [@b9AcE](https://dietpi.com/forum/u/b9AcE)
#### Post date: [30 April 2024 21:02 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/25 "2024-04-30T21:02:28Z")
Just to verify, I tried it anyway, because why not, but… nope:
```auto
# 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.
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [1 May 2024 16:31 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/26 "2024-05-01T16:31:32Z")
New kernel build is ready:
```sh
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):
```sh
modprobe rtw89_8852be
ls -l
```
---
### Author:  [@b9AcE](https://dietpi.com/forum/u/b9AcE)
#### Post date: [3 May 2024 12:42 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/27 "2024-05-03T12:42:43Z")
Sorry for the delay, I was busy on May 1 and needed some rest the next day.
I installed the new kernel
```auto
# 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
```auto
# 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.
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [3 May 2024 12:57 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/28 "2024-05-03T12:57:52Z")
> [@b9AcE](#):
>
> 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.
So far so good. Does `iw` work to scan for SSIDs?
```sh
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.
---
### Author:  [@b9AcE](https://dietpi.com/forum/u/b9AcE)
#### Post date: [3 May 2024 13:18 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/29 "2024-05-03T13:18:14Z")
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
```auto
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](https://f-droid.org/packages/org.bitbatzen.wlanscanner/)) 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.
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [3 May 2024 13:39 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/30 "2024-05-03T13:39:56Z")
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:
```sh
iwlist wlan0 scan | sed -n '/^[[:blank:]]*ESSID:/s/^[[:blank:]]*ESSID:"\(.*\)"/\1/p'
```
We could actually use `mawk` now, to shorten the code a little 🙂:
```sh
iwlist wlan0 scan | mawk -F\" '/^[[:blank:]]*ESSID:/{print $2}'
```
Though, this would choke on `"` characters within the SSID 🤔.
---
### Author:  [@b9AcE](https://dietpi.com/forum/u/b9AcE)
#### Post date: [3 May 2024 13:54 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/31 "2024-05-03T13:54:22Z")
Yeah, it does indeed.
But I believe this is a very unusual and non-standard situation,
so it can probably be ignored unless you run out of other things to do. ;-D
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [3 May 2024 14:03 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/32 "2024-05-03T14:03:42Z")
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 😄.
---
### Author:  [@b9AcE](https://dietpi.com/forum/u/b9AcE)
#### Post date: [3 May 2024 14:22 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/33 "2024-05-03T14:22:59Z")
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.
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [3 May 2024 14:48 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/34 "2024-05-03T14:48:02Z")
Could you test this version?
```sh
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.
---
### Author:  [@b9AcE](https://dietpi.com/forum/u/b9AcE)
#### Post date: [3 May 2024 14:56 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/35 "2024-05-03T14:56:05Z")
That does seem to have worked.
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [3 May 2024 15:48 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/36 "2024-05-03T15:48:42Z")
> [@b9AcE](#):
>
> That does seem to have worked.
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: [https://superuser.com/questions/1263595/create-network-with-ssid-containing-null-characters-0](https://superuser.com/questions/1263595/create-network-with-ssid-containing-null-characters-0)
However, until we can handle them, we should avoid them. Okay let’s see what pattern it matches:
```sh
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.
---
### Author:  [@b9AcE](https://dietpi.com/forum/u/b9AcE)
#### Post date: [3 May 2024 15:54 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/37 "2024-05-03T15:54:22Z")
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:
```auto
# 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"
```
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [3 May 2024 16:19 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/38 "2024-05-03T16:19:29Z")
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.
---
### Author:  [@b9AcE](https://dietpi.com/forum/u/b9AcE)
#### Post date: [3 May 2024 16:27 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/39 "2024-05-03T16:27:29Z")
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?
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [6 May 2024 19:03 UTC](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929/40 "2024-05-06T19:03:52Z")
> [@b9AcE](#):
>
> The grey is my redaction
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?
> [@b9AcE](#):
>
> I did not put back the original “dietpi-wifidb” file yet. Maybe that influenced the grep pattern matching?
`dietpi-wifidb` has no effect on the low level UNIX system tool `iw` 😉.
[Previous page](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929.md?page=1)
[Next page](https://dietpi.com/forum/t/orange-pi-5-should-we-have-switched-kernel/19929.md?page=3)