I tested on this device in router mode with a very basic setup:
Model: ASUS OnHub
Target Platform: ipq806x/chromium
Firmware Version: OpenWrt 23.05-SNAPSHOT r24100-66055df3e0
Packet Steering enabled
Auto channel set on both bands
There was considerable (expected) fluctuation on the 2.4G, which is saturated in my area. Still though the device had better 2.4G speeds back when running on firmware 25.03.3
Upgraded to OpenWrt 23.05-SNAPSHOT r24100-66055df3e0 on all 3, and so far everything is running pretty well.
The Meraki MR-52s (ipq806x/generic ) are running as VLAN'ed APs (dumb AP + guest/IoT networks bridged to associated VLANs), with 802.11r enabled. Everything is running WPA2 because I couldn't make 802.11r work with WPA3 -- but that isn't new to this snapshot.
The x86/64 host (qemu-standard-pc-q35-ich9-2009 ), which is a VM running on Proxmox 7.4 running on a N5100 miniPC is the primary router and also running a Wireguard server, DNS/DHCP (using dnsmasq), NTPd, and dynamic DNS updaters, as well as SQM (using piece-of-cake). DHCPv4 and DHCPv6 client with a /56 prefix delegated.
A couple of issues I've noticed during the upgrade:
The x86 router was running as a UEFI image on Proxmox. The upgrade somehow failed to detect this and installed the legacy-BIOS image, which resulted in the VM not rebooting (it was stuck in the UEFI shell in Proxmox, since there was no EFI partition). This might be on me, or the confusing x86 install / upgrade process, particularly for VMs. But that's still pretty annoying!
Wireless speed tests from this laptop (a 2019 MacBook pro) look to be ~ 30% slower with this version. Interestingly the Wifi info for this laptop shows as NSS 2 for RX and NSS 3 for TX, whereas I'm pretty sure in earlier snapshots it showed as NSS 3 for both RX & TX. Will reconfirm with my M3 MacBook.
Updated a couple of devices, both from 23.05.4 previously. No apparent regressions on either.
Buffalo WZR-HP-AG300H to snapshot-r24098-4d7ad37891.
Upstream is 802.11s mesh on the 2.4GHz radio:
Two VLAN-tagged interfaces on top of that. One interface is unmanaged and part of br-lan while the other is a DHCPv4 client.
Some luci operations take a long time. Not a new issue. I think it's crypto-library related - mbedtls not optimized on this platform?
Netgear WAX206 to snapshot-r24100-66055df3e0.
Upstream on the WAN wired port, to cable modem. DHCPv4 and DHCPv6 client with a /60 PD assignment from the ISP.
One pair of APs, one each on 2.4GHz (20MHz 11n) and 5GHz (80MHz 11ax, DFS channel on US regdomain) with the same SSID/password. Clients typically pick up 2.4GHz first due to longer range then switch to 5GHz after a few minutes. Both part of br-lan.
Couple more APs on 2.4GHz.
802.11s mesh on 2.4GHz with two VLAN-tagged interfaces on it: One provides DHCP/DNS/routing while the other bridges to br-lan.
tinyproxy server.
Pair of OpenVPN clients (for the device itself plus the tinyproxy, not for any client devices/networks directly).
23.05.5 Stable release buggy with DIR-882 rev.A1 (MediaTek MT7621AT/MT7615N)
Enabling 5 GHz wireless resulted in loss of connection to router & internet via network cable connection. Big yellow notice popped up.
Hard reset required so my PC could connect to router.
Enabling 2.4 GHz wireless resulted in loss of connection to router & internet via network cable connection. Big yellow notice popped up.
Hard reset required so my PC could connect to router.
