OpenWrt 22.03.0-rc6 sixth release candidate

por · August 6, 2022, 10:46am

mikrotik,routerboard-wap-2nd (MikroTik RouterBOARD wAP-2nD (wAP))

Seems to works, but wrong MAC address allocation on eth0

[    0.975885] ag71xx 19000000.eth: invalid MAC address, using random address

Work-around: add following stanza to /etc/config/network

config device
         option name 'eth0'
         macaddr '6c:3b:6b:xx:xx:xx'

twinkleLED · August 6, 2022, 12:03pm

Files in /etc are persistent over upgrades. /root files are not

essinghigh · August 6, 2022, 2:24pm

github.com/openwrt/openwrt

Impossible to connect my S21 Ultra to wifi wrt1900ac-v2 mixed WPA2/WPA3 PSK, SAE (CCMP) since upgrading to 22.03 (tested rc1 and rc3)

opened 06:15PM - 29 May 22 UTC

zuzzurro

release/22.03

Since upgrading to 22.03 I cannot connect my S21 Ultra to my wifi using a Linksy…s wrt1900ac-v2 (it worked fine in in all 21.02 releases). There's an endless series of connection attempts resulting in the following line in the logs, but never succeeding. ``` Sun May 29 19:47:05 2022 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 10.10.10.162 xx:xx:xx:xx:xx:xx S21-Ultra Sun May 29 19:47:14 2022 daemon.notice hostapd: SAE: xx:xx:xx:xx:xx:xx indicates support for SAE H2E, but did not use it Sun May 29 19:47:14 2022 daemon.notice hostapd: SAE: xx:xx:xx:xx:xx:xx indicates support for SAE H2E, but did not use it Sun May 29 19:47:25 2022 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated Sun May 29 19:47:25 2022 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1) Sun May 29 19:47:25 2022 daemon.notice hostapd: wlan1: Prune association for xx:xx:xx:xx:xx:xx Sun May 29 19:47:27 2022 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated Sun May 29 19:47:27 2022 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1) Sun May 29 19:47:27 2022 daemon.notice hostapd: wlan1: Prune association for xx:xx:xx:xx:xx:xx Sun May 29 19:47:29 2022 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated Sun May 29 19:47:29 2022 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1) Sun May 29 19:47:29 2022 daemon.notice hostapd: wlan1: Prune association for xx:xx:xx:xx:xx:xx ``` Let me know how I can help troubleshooting this.

"mwlwifi is known to be broken with IEEE802.11w and WPA3/SAE, disable it completely in favour of the older WPA2/CCMP. Given the driver/ firmware situation, this is not going to improve."

Can confirm WRT1900AC v2 & WPA3 does not function with 22.03.0, but as mentioned above there are issues with mwlwifi and WPA3/SAE. I do know that this does work with 21.02, however am not sure why.

patrakov · August 6, 2022, 4:14pm

Installed this on an unused BT HomeHub 5A, with the intention of giving to a friend as a temporary WiFi range extender. Not really satisfied.

It works in my house (well, sometimes goes more than once through the green-flashing pattern before turning the blue LED on after a reboot), but boot-loops in the friend's house. ~~Possibly~~ a power supply issue. EDIT: confirmed as a power supply issue, by replacing the supply.

When the client and the AP are configured simultaneously on the 2.4 GHz radio, they work as expected. The same configuration on 5 GHz (channel 100) doesn't work, only the client is active, the AP never shows up in the scan results. ~~Possibly~~ related to DFS. Problem does not exist with channel 149 if the channel is specified explicitly.

skuzzer · August 6, 2022, 4:37pm

This is still under development. Try the release version 21.02.3 for now?
Worth noting though.

jbrossard · August 7, 2022, 12:05am

WPA3 does not work on any version for the WRT1900AC or ACS, due to a 802.11w bug in the driver which will not be fixed. It only seems to work on 21.02 by making 802.11w optional, but that doesn't actually work in practice. 802.11w is required by WPA3.

huangjinqiu · August 7, 2022, 2:06am

WPA3 works even by making 802.11w required for 21.02. But it doesn't work with disabled.

slh · August 7, 2022, 2:11am

That isn't the question here, jbrossard is not talking about WPA3's requirements (of which IEEE 802.11w is a mandatory part), but mwlwifi being utterly broken (crashing hard) when encountering IEEE 802.11w (and indirectly WPA3, as this needs IEEE 802.11w).

huangjinqiu · August 7, 2022, 2:21am

I am clarifying to this. There are 3 options: "disabled; optional; required" for 802.11w. Even by making it "required", WPA3 still works for my testing.

anomeome · August 7, 2022, 2:27am

Both 88W8864 and 88W8964 FWs are broken as far as WPA3 goes, but 88W8964 devices fail miserably compared to 88W8864 devices, but it is broken regardless, mwlwifi bug from way on back, and there ain't nothing new here.

Edit: thread re issue testing

Neverends4 · August 7, 2022, 2:38am

WAP3 needs 802.11w/MFP, if your client indeed negotiates with WPA3 ONLY mode, then disable 802.11w will break the handshaking.

For WPA2/WPA3 mixed config, if setting 802.11w to required, all WPA2-only clients(old machines, TVs or PC with older wireless NIC like intel 8265 etc.) will fail to connect, only those capable with WPA3 can. Tested myself, though my router is MT7621 based.
For WPA2/WPA3 mixed config, if setting 802.11w optional (this is the default behavior), WPA2-only clients will connect using WPA2 mode, i.e. MFP/802.11w off, and WPA3-capable clients will try to use WPA3 with MFP.
For WPA2/WPA3 mixed config, if setting 802.11w disabled, all clients will connect use WPA2 mode, I think this equals to set the interface to WAP2.

You can try yourself, setting the wireless to WPA3 and 802.11w will automatically changed to "required".

grrr2 · August 7, 2022, 10:31am

probably i miss something while i am trying to set a dual boot setup:

using the x86 release under VMWare, downloading the respective generic-ext4-combined image and after converting to vmdk format i have a working owrt instance. i can boot, login, configure network etc, everything works as should.
then power off owrt and expanding the virtual disk, so the disk capacity is increased from 104MB to 2GB for example. this does not change the existing partitions just adds bunch of free space. then i create a new partition which supposed to hold a 2nd rootfs instance.
so far i have sda1 as boot, sda2 as 1st rootfs (coming from the ext4-combined image) and sda3 as new partition. making a new ext4 fs on sda3 and mount to /mnt, then download the respective https://downloads.openwrt.org/releases/22.03.0-rc6/targets/x86/64/openwrt-22.03.0-rc6-x86-64-rootfs.tar.gz (1) and extract it to /mnt.
after adding a new menuentry to grub.cfg by pointing root to sda3 i can reboot and login to this 2nd rootfs instance.

and then i have problems because it looks the rootfs.tar.gz does not include any network interface kmod so cannot do any sensible thing.

there is https://downloads.openwrt.org/releases/22.03.0-rc6/targets/x86/64/openwrt-22.03.0-rc6-x86-64-generic-ext4-rootfs.img.gz (2) too, which includes 66 kmods under /lib/modules which includes network related ones as well (e.g. e1000.ko) but the aforementioned (1) only includes 49 kmods.
furthermore https://downloads.openwrt.org/releases/19.07.10/targets/x86/64/openwrt-19.07.10-x86-64-generic-rootfs.tar.gz (3) which i assume has the same purpose as (1) in spite of different naming convention also includes 59 kmods including network related ones.

my questions:

why (1) and (2) are different, what is the purpose of each?
why (1) does not include probably the most important kmods? after all owrt is a network appliance network drivers are quite essential, are not?

patrakov · August 7, 2022, 1:01pm

That's because the rootfs is supposed to be used as an lxc container or a chroot, not as something bootable on its own. The networking modules are to be provided by the host system, which you don't have.

grrr2 · August 7, 2022, 1:13pm

this was not the case as i see in 19.07, why it changed?

patrakov · August 7, 2022, 1:14pm

I don't know.

patrakov · August 7, 2022, 1:16pm

Well, I understand, but let's give this -rc a bit of real-world testing and yes I have warned that friend about the -rc.

jithin · August 7, 2022, 2:05pm

is it just for me or did Devs remove custom rules from firewall settings?

dave14305 · August 7, 2022, 2:31pm

There is a different custom include method with the switch to firewall4/nftables. No more firewall.user support.

github.com/openwrt/openwrt

firewall4: design shortcomings in fw4 custom filter chains

opened 11:43AM - 02 Jun 22 UTC

closed 04:14PM - 14 Jul 22 UTC

Shine-

core packages

### Problem description: fw4 custom filter chains ("10-custom-filter-chains.n…ft" or "*.nft") have some logic/design issues. Below are two example cases, and I'm sure there are more. ### Case 1: Background: Firewall rules should always be processed from top to bottom. If one rule is matched, processing should end, so the matched rule can come into effect. This works fine as long as you remain within **only one nft chain**. As soon as you add additional chains, nft behaves differently. A "Drop" rule in any chain will render all "Allow" rules in all previous (lower priority) chains void. This is due to nft's behavior of continuing to process any later chains, even if a rule matches, **until** a Drop is found. So the "top to bottom" approach suddenly applies only to "Drop" rules, not to "Allow" rules anymore. Consequently, this renders fw4's "*.nft" files - which can add additional chains, but not any additional rules in the default chain - quite useless, because they can only be used for "Drop" rules, not for "Allow" rules. ### Problem for Case 1: Due to the nft behavior with multiple chains, at this time, the user doesn't have a possibility to add custom "Allow" rules to fw4. This especially prohibits the user from configuring fw4 like a proper network firewall should be configured: Deny everything unless explicitly allowed - since the "Deny all" last rule will override any previous "Allow" rules from any lower priority chains! ### Case 2: Background: In a stateful firewall, flows that are already handled by a firewall rule should not be sent through the whole rulebase processing again, as this would mean wasting CPU cycles and therefore slowing down firewall performance. This works fine, as long as the default fw4 chains are the **only** chains used. These chains contain an "Accept" rule for "established,related". As soon as the user adds additional chains (without own "established,related" rules), these complete chains are processed for every packet. As already described in Case 1, this re-processing will repeat for each and every chain, as an "Accept" rule will not stop processing later chains. ### Problem for Case 2: By adding simple additional rules as separate nft chains, instead of within the default chains, performance will suffer. ### Suggestion: "*.nft" files aren't currently useful for the purpose one would suppose: quickly adding additional firewall rules that aren't supported in uci/LuCI syntax. While Case 2 is just "inconvenient", but can be solved by adding "established,related" rules to each chain, I don't see how Case 1 can be solved in the current state of fw4 at all. The possibility of adding complete additional nft chains might be useful for special purposes. It is, however, not a feasible way of quickly adding custom firewall rules. Therefore, it should not be the **only** possible way of customizing the fw4 ruleset. Rather, the user should be given an easy possibility of customizing the fw4 default chains, without having to think of all side effects and limits that he might have when using separate nft chains. After all, the standard OpenWRT user, or even the OpenWRT Power User, is not a nft expert!

edneyhelene · August 7, 2022, 6:09pm

After RC4 my Pi4 goes very bad with any other updates including RC6, frequent disconnection that is only solved after reboot, problems installing Kmod Asix driver for the Tplink usb ethernet, between others.

I suggest if some of you could please test the Raspberry pi4 on the latest releases because its unusable for me. I also think that the driver for the USB should come on the default RP4 image, every time having to compile it with it is annoying.

Thanks in advance.

rhester72 · August 7, 2022, 7:49pm

The issue with the driver is known but not solved as of yet.

It's unlikely to ever be included by default, because there is no standard for what particular USB dongle (or more specifically, chipset) any given end user happens to have/use. Many don't use one at all and VLAN the single port.