OpenWrt 21.02.0 Fourth release candidate

https://downloads.openwrt.org/releases/21.02.0-rc4/targets/ath79/generic/packages/kmod-usb-storage_5.4.137-1_mips_24kc.ipk

Maybe you forgot to opkg update?

1 Like

Yup that's it! I'd been using Luci exclusively. I definitely used "Update lists" a few times, but clearly luci's view of packages is different from the command line opkg. Good to know. Thanks!

Also noticing that with my iPhone on 5 GHz network. Transient disconnections. Interrupted YouTube playback. Definitely seems like there's a bug amiss.

Which firmware are you currently running @phinn ? Master Snapshot, 21.02 Snapshot, or Divested? And have you found it to be stable otherwise?

I can confirm that these packages (*usb-storage) are not shown in Luci (C7 v5 on rc4)

1 Like

Observed the same on wndr3700v2

opkg from cli finds *usb-storage

But luci filter and unfiltered finds none

On my Mi Router 4a Gigabit Edition RC4 broke the discoverability of Amazon Echo Devices from Spotify, so I can no longer cast music from spotify to my Amazon Echo-speaeker.
The same problem applies when trying to cast to a Sonos speaker.

It looks like either multicast forwarding, the conversion from multicast from LAN to WLAN (multicast to unicast) is broken or something like SSDP is being blocked.

[Problem does not occur on TL-WPA8630Pv1 which is QCA-based running 21.02.0RC4, so the problems seems to be MT76xx related, Maybe it is due to the lack of igmp-snopping support in hardware of the MT7530-switch? See (1) and (2)]

UPDATE:

The problem was related to a broken umdns-daemon in connection with seccomp.
I discovered the root cause when my dawn-daemon couldn't see other dawn-nodes on the same network.
Errormessage was: daemon.err dawn[x]: Failed to look up test object for umdns

The workaround listed on https://bugs.openwrt.org/index.php?do=details&task_id=3355 works:

cd /etc/seccomp
mv umdns.json umdns1.json
sync
/etc/init.d/umdns restart 

After applying the fix to my Mi Router 4a Gigabit Edition and rebooting the router, my Echo-speakers were visible in Spotify again and the Sonos-app found the Sonos-speakers again.

1 Like

I also have that problem you mention I have the edgerouter x if anyone wants to know, but the loss and high latency only happened in version 19.07 and also in rc2 and rc4, so for now I am in rc1 where the latency is stable.

1 Like

I believe I might have hit an issue with 21.02 RC4 on ASUS Lyra MAP-AC2200.

When I try to enable the second 5GHz WLAN it never works , leaving it in "Wireless is not associated".

Now the order these are as shown bellow in the image.

The available channels in the config for the indicated radio0 (indicated as Qualcomm Atheros QCA9886 802.11nac) are 36-64, while for radio2 (indicated as Qualcomm Atheros IPQ4019 802.11nac) are 100-144.

The logs show this as not being allowed by the HW

Sun Aug 22 23:53:06 2021 daemon.notice hostapd: Frequency 5660 (primary) not allowed for AP mode, flags: 0xf00797b NO-IR RADAR
Sun Aug 22 23:53:06 2021 daemon.err hostapd: Primary frequency not allowed
Sun Aug 22 23:53:06 2021 daemon.warn hostapd: wlan2: IEEE 802.11 Configured channel (132) or frequency (5660) not found from the channel list of the current mode (2) IEEE 802.11a
**Sun Aug 22 23:53:06 2021 daemon.warn hostapd: wlan2: IEEE 802.11 Hardware does not support configured channel**
**Sun Aug 22 23:53:06 2021 daemon.err hostapd: Could not select hw_mode and channel. (-3)**
Sun Aug 22 23:53:06 2021 daemon.notice hostapd: wlan2: interface state UNINITIALIZED->DISABLED
Sun Aug 22 23:53:06 2021 daemon.notice hostapd: wlan2: AP-DISABLED
Sun Aug 22 23:53:06 2021 daemon.err hostapd: wlan2: Unable to setup interface.
Sun Aug 22 23:53:06 2021 daemon.notice hostapd: nl80211: deinit ifname=wlan2 disabled_11b_rates=0
Sun Aug 22 23:53:06 2021 kern.info kernel: [ 2203.726299] device wlan2 left promiscuous mode
Sun Aug 22 23:53:06 2021 kern.info kernel: [ 2203.727551] br-lan: port 4(wlan2) entered disabled state
Sun Aug 22 23:53:06 2021 kern.warn kernel: [ 2203.790835] ath10k_ahb a800000.wifi: peer-unmap-event: unknown peer id 0
Sun Aug 22 23:53:06 2021 daemon.notice hostapd: wlan2: CTRL-EVENT-TERMINATING
Sun Aug 22 23:53:06 2021 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan2 wasn't started
Sun Aug 22 23:53:06 2021 daemon.notice netifd: radio2 (31984): Command failed: Invalid argument
Sun Aug 22 23:53:06 2021 daemon.notice netifd: radio2 (31984): Device setup failed: HOSTAPD_START_FAILED

On the OpenWRT page for MAP-AC2200 https://openwrt.org/toh/asus/lyra_map-ac2200 the following line is noted that might indicated that these are actually inverted - (IPQ4019) is limited to ch. 36-64 while (QCA9886) is limited to ch. 100-140?

Note: The first 5 GHz radio (IPQ4019) is limited to ch. 36-64. The second 5 GHz radio (QCA9886), is limited to ch. 100-140. This is consistent with OEM firmware and is a result of the ART data and the data in the OEM firmware's cal data. 

Edit:
I have tried putting both AC radios on auto for channel selection option and this does not address it.
Also the 'Maximum transmit power' option for both AC channels is left to the default, which is 'driver default'.

Edit2:
This looks like it is the case. Checked on MAP-AC2200 with stock firmware and the radios are indicated as wifi0 and wifi1 for SOC (ipq40xx) and wifi2 as the PCIE one (QCA9886).
Wifi1 is the first 5GHz channel with possible ch. 36-64 while wifi2 is the second 5GHz channel with possible ch. 100-140 (via comparison of the MAC address listed in the GUI Network Map->System Status and the MAC for each within /sys/devices/soc.0/80000.qcom,pcie/pci0000:00/0000:00:00.0/0000:01:00.0/net/wifi2/address, /sys/devices/virtual/net/ath0/address and /sys/devices/virtual/net/ath1/address)

lrwxrwxrwx    1 admin    root             0 Aug 23 11:31 ath0 -> ../../devices/virtual/net/ath0
lrwxrwxrwx    1 admin    root             0 Aug 23 11:31 ath1 -> ../../devices/virtual/net/ath1
lrwxrwxrwx    1 admin    root             0 Aug 23 11:31 ath2 -> ../../devices/virtual/net/ath2
lrwxrwxrwx    1 admin    root             0 Aug 23 11:31 br0 -> ../../devices/virtual/net/br0
lrwxrwxrwx    1 admin    root             0 Aug 23 11:31 brg0 -> ../../devices/virtual/net/brg0
lrwxrwxrwx    1 admin    root             0 Aug 23 11:31 eth0 -> ../../devices/soc.0/c080000.edma/net/eth0
lrwxrwxrwx    1 admin    root             0 Aug 23 11:28 eth1 -> ../../devices/soc.0/c080000.edma/net/eth1
lrwxrwxrwx    1 admin    root             0 Aug 23 11:31 eth2 -> ../../devices/soc.0/c080000.edma/net/eth2
lrwxrwxrwx    1 admin    root             0 Aug 23 11:31 imq0 -> ../../devices/virtual/net/imq0
lrwxrwxrwx    1 admin    root             0 Aug 23 11:31 imq1 -> ../../devices/virtual/net/imq1
lrwxrwxrwx    1 admin    root             0 Aug 23 11:31 lo -> ../../devices/virtual/net/lo
lrwxrwxrwx    1 admin    root             0 Aug 23 11:31 miireg -> ../../devices/virtual/net/miireg
lrwxrwxrwx    1 admin    root             0 Aug 23 11:31 wifi0 -> ../../devices/soc.0/a000000.wifi/net/wifi0
lrwxrwxrwx    1 admin    root             0 Aug 23 11:31 wifi1 -> ../../devices/soc.0/a800000.wifi/net/wifi1
lrwxrwxrwx    1 admin    root             0 Aug 23 11:31 wifi2 -> ../../devices/soc.0/80000.qcom,pcie/pci0000:00/0000:00:00.0/0000:01:00.0/net/wifi2

Weird enough there is no /sys/devices/soc.0/a800000.wifi/net/wifi1 on stock fw device.

Try changing your channel to 36 on the QCA9886 chip and 149 on the IPQ4019. Also make sure your region is set correctly in the advanced wireless setup.

2 Likes

master and 21.02 have for default firewall configuration

option syn_flood

but luci wants to change this to

option synflood_protect

which one is valid (or both?)

Hello,
I have try this new version with a Xiaomi R3P but it is not ready. Afetr sysupgrade I see my all wifi network and I can connect but ... without internet acces. Also no Luci or ping ... It is dead for me !
I have upgraded from 19.07.07 with Luci.

After I have check with UART connection and 21.02 is ready !
I see the good IP adress with IP ADDR command.
Very strange ...
Finaly a have reseted and after I have see the router with standard adress 192.168.1.1 -> this release is good for my router but not my config !!
When I relead my config it is always the same ... probably a network mistake into my router network config !
I have also tested with last snapshoot with the same result.
I think my config is not ready with this new version and honesty I have not wish to rebuild manualy all config.

Finaly I have put version 19.07.08 and it is ready.

Any idea about this issue ?

Thank you,

Jean-Charles

From the wiki:

syn_flood           boolean  no  0  Enable SYN flood protection (obsoleted by synflood_protect setting).
synflood_protect    boolean  no  0  Enable SYN flood protection. 
1 Like

You will likely need to redo your config because of DSA change:

Hello,
Thank-you for your reply. Effectively it is probably the issue.
Because it is not ready for one automatic upgrade this issue is a repeat common question.

Ok why not ... but into your link I see one message: " There is no migration path for targets that switched from swconfig to DSA. In that case, sysupgrade will refuse to proceed with an appropriate error message:
Image version mismatch. image 1.1 device 1.0 Please wipe config during upgrade (force required) or reinstall. Config cannot be migrated from swconfig to DSA Image check failed"

But in my case I have don't see this message.
-> problem warranty for all people in this case ...

Thank you, I actually forgot to select the region in the wireless for that interface. Now I can select other channels on my IPQ4019.

Nevertheless I believe the above issue still applies.
The two restrictions appear to be inverted in the DTS https://github.com/openwrt/openwrt/blob/master/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-map-ac2200.dts

&wifi1 {
    ...
    ieee80211-freq-limit = <5470000 5875000>;
};

&pcie0 {
    ...
    bridge@0,0 {
        ...
        wifi2: wifi@1,0 {
            ...
            ieee80211-freq-limit = <5170000 5350000>;
        };
    };
};

I will try to test this change in a build (swapping the DTS freq limits).

Hello,

I have checked and finally I have the error message about wrong conversion to DSA.
Read to quickly ... and click to force also. -> I'm a bad user :slight_smile:

I'd been trying to debug this issue on my C7 V2 (19.07.4) for a couple of weeks now. I was planning to replace the entire cable at this point now. It is connected to EA7300 V1 running 21.02.0-rc3 on the other end of the cable. If EEE is disabled on Openwrt by default then that might not be the culprit? Is there a way to verify that it really is disabled?

Running 21.02-rc4 on a Linksys WRT1900ACSv2. Just want to report that I'm experiencing issues with my LAN, seemingly at random, "losing sight" of my Apple TV. It will work perfectly at first e.g. I can be streaming a movie from my laptop to my Apple TV and an hour into the movie it'll stop because my laptop can no longer see the Apple TV on the network.

A restart of the laptop and Apple TV doesn't help but only a reboot of the router fixes the issue, which leads me to believe it is related to the rc4 release. The issue has not been present prior to upgrade to this version.

Has anyone else experienced this?

For the switch ports on an Archer C7, a first step would be to check the output of

swconfig dev switch0 show

and look for the lines containing "enable_eee".

If you have a managed switch at hand, depending on the vendor/firmware, you might also be able to see the status there if you connect the Archer C7 to the switch. At least on my Cisco SG250 switch I can see whether a device connected to a port supports EEE.

If you don't have a switch or have reason not to trust the output of swconfig, you could try to explicitly disable it by setting the option enable_eee '0' for the port in question in OpenWrt's network configuration and see if that helps.

On devices that use the new DSA switch configuration, you could use ethtool to determine the status of each port. The Archer C7 has not (yet) been ported to the DSA model, though. So, that won't work directly on the device.
But if you can connect a Linux computer to the port in question of your Archer C7, then you can run

ethtool --show-eee eth0

on the Linux machine and check the lines "Link partner advertised EEE link modes" to see whether the Archer C7 advertises EEE support (replace eth0 with the ethernet interface name of your Linux machine).