If you use test versions, why are you surprised at their unstable operation? Today 2 GHz works poorly, tomorrow 5 GHz will work poorly...
Such is life and it is not always fair.
i made a firmware today for this device
using kernel 6.6
everything seems ok except I have to disable AX mode (i.e set N for 2.4 / AC for 5) or the family samsung tv won't connect
the firmware is patched for VHT to work over 2.4 (qam256) as long as you add
option vendor_vht '1'
under the 2.4 radio section, maybe that's why AX mode doesn't work, but VHT over 2.4 ghz does work
link to firmware here if anyone is interested in trying it
I had a similar problem, I'm sure I upgraded without keeping the files and then manually followed the previous config file zip to reset it.
My last firmware kernel was 6.1.78, after switching to 6.1 kernel on the mainline.
I also tested a few things: 1. Same firmware, on the one that is a mesh node at the far end, pinging it's IP gets normal values, both routers are in HE160 mode and
connecting with 802.11s
2. no high latency at 2.4G no matter how you tweak it
The top one is 5.2GHz, the bottom one is 2.4GHz
The firmware kernel version is now 6.1.80, and this version has been tested for several days with the same problem.
@nbd - do you have any thoughts? I noticed that mt76 has not been updated between to problematic commit so that kind of rules changes to it out unless something else changed that requires a change to mt76?
@darksky, which exact version did you build?
@nbd - I believe the last-good was 5ec6c58738 and the first bad (for me was) db0d7cf6a1 but based on the post by @PussAzuki a few above, 79ee4cb039 is also bad and I think closer to the last-good than mine is.
I can't believe you got nbd to post on the forums.
FWIW, I'm on 53252eeb3b (well past the "last-good" point for you) with my Redmi AX6000 as my Access Point in WDS mode, no issues with 5ghz for me for either the WDS client or clients connected directly. Channel 149, Width 80mhz, AX mode, WPA2 / WPA3 Mixed encyption
WED off (doesn't work with WDS), Software and Hardware flow offloading on, packages are:
wpad-openssl
luci-ssl-openssl
htop iperf3 luci python3-speedtest-cli
luci-app-statistics collectd-mod-cpufreq collectd-mod-ipstatistics collectd-mod-ping collectd-mod-processes collectd-mod-sensors collectd-mod-thermal collectd-mod-wireless
libustream-mbedtls removed
I don't have an AX6000, but I will run a few tests with the latest version on a different MT7986 device. Do the latency issues change when you reconnect, or do they remain across reconnects?
In my limited testing, once this bug was triggered, reconnecting did not recover it. Connections were dead until rebooting the AP.
I just checkout that commit and am building the firmware for my device. I will try it and report back.
The last time I posted, I believe the bug was not triggered right away, maybe took 5-6 hours of uptime before it hit, so it may take some time for me to know.
1 Like
i might try making a build with this mt76 branch instead
he's added a fair amount on top of the usual mt76
i'll test that later on today see if ther's any difference
The last I tested to have a problem was the version after redmi ax6000 change to fitblk and then led changed as well.
I've been using it this way with no problems with this patch
Now I just noticed that irq is all over cpu0.
Also redmi ax6000 doesn't seem to have WED on by default anymore, last time I remember it being on by default it was fixing a startup issue with the stock version of the firmware
Could someone please test wifi 2.4 at 40mhz on cell phones?
Which commit + that patch is working for you?
I mean it worked that way before with no problems until the recent update...
br-lan: received packet on bat0 with own address as source address
Some time ago I followed the openwrt wiki to use batman+dawn, and I don't know what was wrong, but I got this error often; then I used 802.11s and didn't have this problem for a long time, but a few days ago I got a similar error when I didn't use batman after updating to the problematic firmware (the interface in the log of the error was not bat0, of course)
I found some discussion under these two commits, maybe the high latency has something to do with these?
I'll try deleting them all and see if the latency problem persists.
@PussAzuki @darksky You might want to follow along here and try the patch uploaded recently: https://github.com/openwrt/openwrt/commit/95e633efbd1b4ffbbfc2d8abba2b05291f6e9903#commitcomment-139794215