OpenWrt 21.02.0 second release candidate

The Kernel docs calls them "swpX" which is nice too
DSA Architecture — The Linux Kernel documentation

It is not LuCI itself, but the underlying iwlinfo (libiwinfo) which can't find the correct libubus.

I am proposing (for master) a more permanent fix for the problem with

Not maybe luci itself but luci or anything else with luci in its name isn’t installing on rc2 so this is very much a partymood cooler for the rc2 release.

On Totolink x5000r configuration autogenerated with "wifi config" doesn't work correctly with LUCI (unable to set frequency, channel analysis shows only radio0 with incorrect frequency):

wifi down;rm /etc/config/wireless;wifi config;wifi up;sleep 5;echo radio0;iwinfo radio0 info; echo radio1;iwinfo radio1 info
'radio0' is disabled
'radio1' is disabled
'radio0' is disabled
'radio1' is disabled
radio0
radio0    ESSID: unknown
          Access Point: 00:00:00:00:00:00
          Mode: Unknown  Channel: unknown (unknown)
          Center Channel 1: unknown 2: unknown
          Tx-Power: unknown  Link Quality: unknown/70
          Signal: unknown  Noise: unknown
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11nac
          Hardware: 14C3:7915 14C3:7915 [MediaTek MT7915E]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1
radio1
No such wireless device: radio1

Generated device sections:

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
        option htmode 'HT20'
        option disabled '1'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0+1'
        option htmode 'VHT80'
        option disabled '1'

Removing path and forcing correct phy makes luci/iwinfo happy:

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option disabled_path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0
        option phy 'phy0'
        option htmode 'HT20'
        option disabled '1'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option disabled_path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0
        option phy 'phy1'
        option htmode 'VHT80'
        option disabled '1'
root@ap01:~# echo radio0;iwinfo radio0 info; echo radio1;iwinfo radio1 info
radio0
radio0    ESSID: unknown
          Access Point: 00:00:00:00:00:00
          Mode: Unknown  Channel: unknown (unknown)
          Center Channel 1: unknown 2: unknown
          Tx-Power: unknown  Link Quality: unknown/70
          Signal: unknown  Noise: unknown
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11bgn
          Hardware: 14C3:7915 14C3:7915 [MediaTek MT7915E]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0
radio1
radio1    ESSID: unknown
          Access Point: 00:00:00:00:00:00
          Mode: Unknown  Channel: unknown (unknown)
          Center Channel 1: unknown 2: unknown
          Tx-Power: unknown  Link Quality: unknown/70
          Signal: unknown  Noise: unknown
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11nac
          Hardware: 14C3:7915 14C3:7915 [MediaTek MT7915E]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

Next strange thing: I have two such devices - both have same MAC on phy1:

root@ap01:~# cat /sys/class/ieee80211/phy1/macaddress
00:0c:43:4a:21:4e
root@ap11:~#  cat /sys/class/ieee80211/phy1/macaddress
00:0c:43:4a:21:4e

OpenWrt devs, thank u all.
Very cool to be up 2 date with OpenWrt.

1 Like

Hi,

I updated my X86_64 router (thanks to the UEFI image !!) with 21.02.0-rc2 and I want to declare a bug (or a strange behaviour) about DHCPv6.

All is working fine if I choose a 12h (or more) lease time.
If I configure a shorter lease time (2m, 15m, 1h or even 11h) no DHCPv6 lease is granted (to any host), only SLAAC is working.
However, I thought that the lease time parameter only concerned DHCPv4 but it seems to also impact DHCPv6 server.

I had to put my old WD N750 back into service under OpenWRT 19.07.7 which does not have this problem of lease time (because 19.07.7 has no X86_64 UEFI capable image to deploy it on my X86_64 router)

Regards
Herve

For those using WRT1900ACSv2 wanting to run 21.02.0-rc2: Reporting that WiFi, Samba4, OpenVPN, BlockMount, SQM, WPA3, and separate bridge networks (not necessary VLAN) seem to be working extremely well on uptime Day 1. Formally used David 19.07 builds. Briefly experimented with Divested Builds, left for Samba4 support.

5GHz performance significantly improved with irqbalance. Change 'enabled' from '0' to '1' in '/etc/config/irqbalance'. I would argue this performance gain to be essential. Simultaneously disabled 802.11w which was known to provide issues on mwlwifi and enabled SQM, which may be confounding variables.

UPDATE: Also required a patch to fixed high latencies for the mwlwifi driver. Disable tx_amsdu.

echo "0" >> /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo "0" >> /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu
2 Likes

Yep same here on my WRT32X, same mvebu platform. Everything running awesome since they applied that fix to samba4. No issues, USB3 read/write at 120MB/s, SQM cake maxing out my 500/35mbits cable modem, adblock, irqbalance added, etc. 1 week uptime.

1 Like

Upgraded one of our Meraki MR24 access points to 21.02.0-rc2, saving settings. Worked perfectly after first boot, and also on subsequent reboot after LuCI-triggered auto migration of interface and device config in /etc/config/network. Setup includes:

  1. 2 VLANS on 2 SSIDs per radio on 2 radios
  2. LED customizations
  3. Persistent disabled services per OpenWrt 19.07.7 service release - #34 by spaine

which all migrated flawlessly. Like the new Channel Analysis feature. Nice work devs and many thanks!

There were a bunch of us on Linksys/mvebu having connectivity issues with rc1 that took a day or two to notice it as it occurred seemingly at random. But hopefully it's fixed in rc2, please report back if you encounter any issues.

Hi,
I just wanted to let you know that TP Link TL-WR810N v1 works well with RC2. Thank you @hauke for backporting the fix. Free Flash is now running low, but that was expected and it is still OK.

I can confirm RC2 works well with these devices:

  • TP-Link TL-WR810N v1 (works now, Flash is low but sufficient, I have been warned)
  • Fritzbox 7320 (USB has power without setting GPIOs, Ethernet not tested, used as a repeater, requires a restart for changes to WiFi settings though)
  • Ubiquiti UniFi AC LR, no issues whatsoever
  • TP-Link Archer C2600 v1 (tested 5x devices, all good and no reboots with the scheduler set to performance echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor; echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor)
  • TP-Link TL-WR1043ND v1 (RAM is now very low, I have been warned, but it still works, opkg update fails though unless adding swap via USB-stick which works but is sloooow)

Even WDS with WPA3-SAE works across different vendors without issues, nice.

Thank you for this great firmware!

I think I'm starting to notice connectivity issues particularly with the 5GHz networks and apple devices. Some incredible lag and difficulty with new websites loading. Trying to read and see if I find an answer, but at least some others indicate it could be related to the wifi driver. The current driver is mwlwifi firmware-88w8864 2020-02-06-a2fd00bb-2.

@phinn any ideas?

Update. Found this in Divested build's archives: [PATCH] mwlwifi: Disable tx_amsdu

echo "0" >> /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo "0" >> /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

This fixed the high latencies! I have no idea how to install a patch. I am extremely novice. BUT I was able to place the command in luci > startup > local startup. (Probably could have done nano /etc/rc.local)

# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

echo "0" >> /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo "0" >> /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

exit 0

There's also a CPU patch in the Divested archives that I haven't yet tried.
[PATCH] ARM Cortex-A9: build the userspace with Thumb-2 instructions
Thumb-2 code is denser than pure ARM, reducing RAM usage and improving performance due to better instruction cache footprint.

The mvebu issues with rc1 was lost connection. I use a Linksys WRT1900ACS v2.

There was a discussion in the rc1 thread where I believe they identified the cause of the connectivity issues. I'm a novice myself so wasn't able to follow the details, just hoping it'll get fixed in a future release.

Thus far I haven't noticed dropped connections. Hoping that my latency patch (disable tx_amsdu) fixes my performance issues.

Will the dark matter theme work ? Does anyone know or have tried it ?

I have not had any WiFi 5GHz issues on mine. Haven't checked latency as most of my network is hardwired other than a couple iPhones and a ThinkPad X1. I didn't think those WiFi commands were needed anymore at least not on the WRT32X (or WRT3200ACM), but maybe on yours.

rc2 seems to work fine on TP-Link Archer C7 (v2 and v4) and gl-inet AR750. Although I can't get iPhone tethering over usb to work (ipheth driver). I tested on fedora (kernel 5.12.9-300.fc34.x86_64) and it worked fine there. rc2 has 5.4.119, latest upstream is 5.4.124. Not sure if it will be fixed in that version though. Will next rc or final release still have a newer kernel or are we stuck on 5.4.119?

Thx!
Guy

1 Like
  • Some discussion and patches regarding mvebu architecture changes (thumb and vfpv3). You will of course have to build compile your own image.
  • From the discussion on the mwlwifi github the amsdu issue was only relevant to FW for 88W8864, and you do not want to disable if it can be avoided.
/etc/rc.local
echo "0" >> /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu && echo "0" >> /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu && logger "AMSDU Disabled"
3 Likes

Nobody has the same problem ?

Ah thank you for clearing that up with AMSDU, my WRT32X has the 88W8964 no wonder I didn't have the issue.