OpenWrt 21.02.0 third release candidate

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.

2 Likes

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.

1 Like

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.

Yeah I do update the package listing but they’re still missing. I’m on a Linksys WRT1900ACS v2.

Device: dir-1960:

 OpenWrt 21.02.0-rc3, r16172-2aba3e9784
 -----------------------------------------------------
root@OpenWrt:~# opkg list | grep -e wireguard | grep -v i18n
kmod-wireguard - 5.4.124-1 - WireGuard is a novel VPN that runs inside the Linux Kernel ...
luci-app-wireguard - git-20.244.42172-21563a2 - WireGuard Status
luci-proto-wireguard - git-21.163.62622-a6a6d61 - Support for WireGuard VPN
wireguard-tools - 1.0.20210223-2 - WireGuard is a novel VPN that runs inside the Linux Kernel  ...

It is also a driver parameter.

echo "Y" > /sys/module/mwifiex/parameters/disable_tx_amsdu

Oh, you were asking about which software version is being used. I'm running OpenWrt 21.02.0-rc3, r16172-2aba3e9784.

After updating the opkg lists, I do not have the "wireguard" or "kmod-wireguard" packages availble. Besides the luci-i18n packages, the only ones I have related to wireguard are luci-proto-wireguard, wg-installer-client, wg-installer-server, wg-installer-server-hotplug-babeld, wireguard-tools, luci-app-wireguard.

So this is kind of strange. Anyone know why they're missing?

Hi,
Do you mean
echo "0" >> /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu

should be changed to
echo "Y" > /sys/module/mwifiex/parameters/disable_tx_amsdu
?

One is the driver for radios 0 and 1, the other is the driver for radio 3.

I suppose this should be used in addition to the other command but it seems the path doesn't exist? I realize the path for the other command doesn't exist either. Do these commands really work then?