OpenWrt 22.03.0-rc6 sixth release candidate

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'

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

1 Like

"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.

1 Like

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.

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

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.

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

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).


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.

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

1 Like

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

  1. 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.

  2. 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.

  3. 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".


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 (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 (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 (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?

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.

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

I don't know.

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

1 Like

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

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

1 Like

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.

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.