You won't ever be able to install any packages for a snapshot a day or two after the snapshot was created as it will be wiped and replaces by the next snapshot
Your options are
find out which snapshot was used and download and prepare a new SD cars with latest snapshot and promptly install any packages you need.
use imagebuilder to build your own images.
wait/check for a release image to be available for your device
I think this is not that simple, as they modified the official OpenWRT RC snapshot by including some drivers supporting their board (mainly for the additional NIC on the board). Unfortunately I am not that big Linux guru to recompile a snapshot by including the required drivers, etc.. DFRobot told me on their website that 21.02 will officially support their product once it will be finally released, so I assume I just need to wait a bit longer and fingers crossed that the final version of 21.02 will contain the right version of the KERNEL required for my packages.
Thanks,
B.
In that case you need to contact the manufacturer.
Yes it is.
You talk about security updates for the Kernel, 108 to 132! Not the kernel version.
132 was installed in 21.02-snapshot 40hours ago. 128 was installed at 2021-06-26.
108 was installed at 2021-03-27. That is even before rc1 was released!
We run rc3 or newer for 21.02 nowadays so the fault isn’t OpenWRT. It is the manufacturer that has made that firmware to begin with.
Thank you for the clarification. Since they are claiming that that official version of 21.02 will support this board with CM4, I still think the only thing I can do is to wait. Or... I should try RC3 on my router as it should already included all the needed drivers, because it is so close to the production version. Generally it uses the built in ETH of the CM4 and an additional RTL8111 hooked up to the PCIe of the CM4 so it doesn't seem a very exotic solution and hardware components. Which version of the RC3 should I try to install?
CM4 IoT Router Board Mini for Raspberry Pi Compute Module 4 Wiki - DFRobot
Should this be the right place for CM4?
Index of /snapshots/targets/bcm27xx/bcm2711/ (openwrt.org)
You can create a custom image using https://chef.libremesh.org/ with all the packages you want included in the list.
I suggest sticking to 21.02 RC releases rather than 21.02-SNAPSHOT or Git "master" branch SNAPSHOT.
Based on How to install RTL8111 network card driver on 19.04 - #2 by slh, kmod-r8169 is the kernel module for RTL8111 PCIE Adapter.
Hello,
I was able to flash the right factory image (ext4). The thing is that openwrt works out of the box with the RTL8111 controller DFRobot was added to the board, and cannot recognize the CM4's built-in ethernet controller. This is the output of the lspci command:
root@OpenWrt:~# lspci
00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2711 PCIe Bridge (rev 20)
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
This is kind of strange as the SOC for CM4 is exactly the same as for RPI4. So I would expect that the built-in controller to work out of the box and not the RTL8111.
Should I install any kmod package in order to get it working?
I think the built-in RPi 4 Ethernet Controller goes directly into CPU, not even through PCIE. So maybe it doesn't show in "lspci" list. Do you see both "eth0" and "eth1" in the output of "ip link show" command?
I am using RPi 4B with OpenWRT 21.02-rc3 + RTL8152 USB 3.0 Ethernet Adapter for WAN. My "lspci" output is:
00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2711 PCIe Bridge (rev 10)
01:00.0 USB controller: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller (rev 01)
"lsusb" shows:
Bus 002 Device 002: ID 0bda:8153 Realtek USB 10/100/1000 LAN
This is the output of that command. I guess I am not...
root@OpenWrt:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 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 mq master br-lan state UP qlen 1000
link/ether dc:a6:32:fe:64:16 brd ff:ff:ff:ff:ff:ff
3: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether dc:a6:32:fe:64:16 brd ff:ff:ff:ff:ff:ff
Something is wrong in the firmware image that's flashed right now. Can you flash the image from https://downloads.openwrt.org/releases/21.02.0-rc3/targets/bcm27xx/bcm2711/? You may have to install "kmod-r8169" package manually after flashing to get access to the RTL8111 PCIE Ethernet Port.
It is working now (used the firmware you linked + kmod), thanks.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 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 mq master br-lan state UP qlen 1000
link/ether dc:a6:32:fe:64:16 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether e6:01:41:a2:45:9a brd ff:ff:ff:ff:ff:ff
4: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether dc:a6:32:fe:64:16 brd ff:ff:ff:ff:ff:ff
Why the bridge device (br-lan) is created? Its a bit confusing. Should I remove it?
I think a bridge device needs to exist if you are using the WiFi (WLAN) as part of LAN network. If you are not using WiFi, I think you can remove the "br-lan" and directly use "eth0" instead.
Has anyone gotten 802.11s to work with wolfssl? I’m getting a mesh-sae-auth-failure error. Switching to OpenSSL works fine
R7800 to R7800
I've got the same issue with wifi radio behaving erratically.
It's been an issue for me since RC2, but not from the onset. It came lately, that's why I moved to RC3.
Now, I'm using OpenWrt 21.02.0-rc3 r16172-2aba3e9784
I hope we'll soon get a patch for it.
D-Link DIR-878 Rev. A1
WLAN: MediaTek MT7615N
Same problem with the D-Link DIR-882 Rev. A1 tested/mentioned earlier,
During first day of testing, encountered an android smartphone on 5 GHz WiFi occasionally displaying: Connected, no internet.
Signal strength was excellent.
Connecting to 2.4 GHz WiFi then switching back to 5 GHz resolved issue.
Did not notice anything in the system log.
Halted test of RC3
and
Tried two different development snapshots, such as the recent r17187-ca31755af9. Same problem.
unfortunately this release does not work with clearfog pro when using an ath10k based wifi chip, see https://bugs.openwrt.org/index.php?do=details&task_id=3948
not sure since when this problem occurs, guess its related to the kernel version
if anyone can recommend another wifi card (mini pcie full size), please let me know
Target: x86/64
I have been struggling to get UPnP working with an Xbox with recent OpenWrt versions. From what I can tell, its related to IGDv1 vs IGDv2 and recent versions of minupnpd.
Looking at UPnP port forwarding not working for Windows 10 and Xbox One, I see https://github.com/openwrt/packages/pull/14656 was merged into trunk, and I can confirm on latest snapshots that using miniupnpd-igdv1 fixes my issue.
Is there any chance this could be merged into the 21.02 branch?
I also wish to report that my Linksys WRT1900ACS v2 has been running great for about a week with this new release. Thank you to all the devs who fixed the Linksys connectivity issues that were present in the earlier release candidates.
Also, applying the tweaks mentioned in the quoted post has resulted in huge performance improvements. Nothing has been measured but it sure feels like there's a noticable difference. Thanks to @User34 for sharing.
But is there no wireguard or kmod-wireguard package available in opkg for this release? Seems to be missing for me.
I am on rc3 for a few days. There is a mod package listed for wireguard.
Did you update the opkg package list first?
If it still does not show for your device, probably drop your full device name here.