I am wooden too, but its a three story house plus basement over 4k square feet. My electricity is free as I have solar and I only pay the connect fee to the grid as I only use the grid in emergencies or to charge my batteries at very low rate during off peak on a different plan. So power is not a concern as I produce more than I use.
1 Like
I just re-flashed @lytr 's firmware build with the option to not keep settings. I then did the bare minimum to test without any other potential settings changes conflicting:
- Connect via SSH to change the LAN IP, gateway, and DNS server via CLI so that I could then install luci for the webui
- login to the webui
- disable (ignore) DHCP on the LAN interface
- edit the default OpenWRT SSID on radio0 (5ghz) only to add WPA2-PSK encryption and key, then hit save
- When back at the Wireless settings page it somehow turned that small change into a lot of changes that results in doubling the amount of default OpenWRT SSIDs. I clicked to revert the change
- Re-entered the change to the default OpenWRT SSID on radio0 (5ghz) to add encryption, then hit save
- Now the pending changes only reflected what I actually changed, so I clicked to Save & Apply.
- Now it was broadcasting, so I connected to it with my laptop (Intel AX210 wifi card) and still had the exact same constant disconnect issues.
So I dunno. At this point since seems like I'm apparently the only one having an issue then either:
- I have some currently unknown sub-variant of the hardware that isn't fully compatible with this build (the model is marked MX4300 on the bottom)
- I've just been super unlucky and happen to try the majority of devices that don't stay connected, which would mean nobody else has tried connecting to the 5ghz AP with an Intel AX210, AX211, or 7260 wifi cards or a Steam Deck (LCD, not OLED). Please note the best way to reproduce this issue is to have ONLY one client device connected to the AP at a time. For whatever reason, having a 2nd stable client device connected to the AP (such as a Pixel 7 phone or Nintendo Switch) seems to mysteriously stabilize the unstable client. I haven't tried 2 unstable clients at once to see how that behaves. EDIT: If by some chance it does become stable for you with one of the problematic devices (while only it is connected, see if the stability survives a reboot of the MX4300. It never did for me.
Does the problem exist when you use AP on 2.4GHz (radio1) ?
radio1 / 2.4ghz Seemed stable. Granted I haven't extensively tested it, but it stayed connected with no dropped pings for the 10 or 15min sessions I'd let it sit there. On 5ghz the problem devices can't even stay connected a minute.
Try to set the country code on radio0 to US specifically instead of "driver_default" to see if it helps.
I just did a test with my computer with an Intel AX210 and I'm not having any connection issues. I set it up like you said with a unique access point so it would be the only device.
I should mention that I am specifically running the qualcommax-2540ea6 build.
The luci status page on mine shows this, so I assume it's the same:
OpenWrt SNAPSHOT r0-2540ea6 / LuCI Master 24.212.79282~65b8002
I'd done that in my previous testing before the re-flash and it didn't help. Just tried it again now and still the same.
I've just built the latest qosmio-based image. Try it to see if it helps anything for you. Qosmio added a bunch of ath11k patches in his repo. This image has built-in NSS acceleration. Do not enable software offloading with this image.
2 Likes
After power cycling, now I am getting the same issues.
Error messages look the same and I had the same issues with ping.
After power cycling, now I am getting the same issues.
Well it's nice to know it seems to be an actual issue and I'm not just unlucky/crazy 
I've just built the latest qosmio-based image. Try it to see if it helps anything for you. Qosmio added a bunch of ath11k patches in his repo. This image has built-in NSS acceleration. Do not enable software offloading with this image.
Thanks! I tried this out and it seems to be an improvement. I was disappointed at first because right after I brought the AP up on radio0 it had the same issue after I connected to it, but after a reboot it seems fine. I tried multiple more reboots and a power cycle and it seems stable.
I'll need to do more extensive testing. I'm a little paranoid since it initially had the same issue before rebooting, but it's promising that I was able to easily get it to work.
I have installed today Lytr build. installed LUCI .. Enabled Radio 0. It working fine .. no signal drop and getting speed same as I get from my Asus router.
Tried to install Wireguard however it did not work due to Kernel version issue ( 6.6.43 in current build while Wireguard package for 6.6.45 ) ..
I am new to OpenWRT and first time installed it. Also want to thanks to all developer for working on it.
installing kernel modules as binaries from different sources than the project itself is risky. its not just the kernel version. since the kernel configuration might be also different it can results in obscure errors and crashes even if the kernel version matches
1 Like
I couldn't find the checkbox in LUCI to enable "802.11r Fast Transition" checkbox when set this router as Access Point mode. Does this mean the wpad driver is not loaded in this fork?
Anyone loaded @lytr 's build tried the 802.11r - WLAN Roaming with luck yet?
I'm using 802.11r on @lytr 's build; looks ok to me
To those having connection issues, try disabling 802.11w Management Frame Protection. It can be found in the Wireless Security tab of your wireless AP config.
It might not be the solution but worth trying. I have had issues with that setting on some clients in the past with other routers.
UPDATE: Try setting it to required not disabled
1 Like
FYI, if anyone needs to purchase more it's back on woot, but for $20 https://computers.woot.com/offers/linksys-ln1301-wifi-6-router-4
7 Likes
I think something happened and some files were removed.
+ curl -f --connect-timeout 20 --retry 5 --location https://sources.cdn.openwrt.org/nss-firmware-2024.08.04~794fe373.tar.zst
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 146 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404
Download failed.
+ curl -f --connect-timeout 20 --retry 5 --location https://sources.openwrt.org/nss-firmware-2024.08.04~794fe373.tar.zst
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 146 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404
Download failed.
+ curl -f --connect-timeout 20 --retry 5 --location https://mirror2.openwrt.org/sources/nss-firmware-2024.08.04~794fe373.tar.zst
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 153 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404
Download failed.
No more mirrors to try - giving up.
nss-firmware-2024.08.04~794fe373.tar.zst: Download from https://github.com/qosmio/qca-sdk-nss-fw.git failed
nss-firmware-2024.08.04~794fe373.tar.zst: Cannot fetch commit ts:
/repos/qosmio/qca-sdk-nss-fw/git/commits/794fe3732fca4ef9b74e7be6f621d160d831b636: HTTP Error 503: Service Unavailable
/repos/qosmio/qca-sdk-nss-fw/commits/794fe3732fca4ef9b74e7be6f621d160d831b636: HTTP Error 503: Service Unavailable
I think I shot myself in the foot by deleting the cloned directory and starting from scratch. I Check the links and the files are not there.