MT6000 custom build with LuCi and some optimization - kernel 6.6.x

Finally I get also the background radar...

phy1-ap0: DFS-CAC-START freq=5180 chan=36 chan_offset=0 width=5 seg0=5250 seg1=0 cac_time=60s (background)

it was not working good before... on next release. Let me test it better


Long time ago we even played competitively, but now due cheaters and bad game design you cant enjoy and take this game seriously, and of course there a lot of games better but when you play something for over 15 years and the team is big enough, there is a lot of people who is not flexible to look into other game…. So we continue to eat same …. just to continue playing together :joy:

Yea for sure, when it comes to multiplayer it's all about what you can play together more so than the game itself. I've spent a ton of time with friends in Battlefield, CS, and PUBG over the years.


Are these changes being pushed to the official openwrt release?

Which RPS settings did you use? Any other setting of note?

Your results are fantastic!

Strange...the new build gives me ~2x higher unloaded latency and 30% lower bandwidth.

Previous "Test 2" build:

New "RC 1" build:

No SQM, HFO and SFO enabled, WED off. Using iPhone 13 mini.

Edit: I shutdown my older MacBook that was logged into the router during testing, and I was then able to achieve similar speeds as the previous build. Maybe an Airtime fairness issue?

I use pretty standard settings, reading nbd github the best is enabled -> 128.

There could be a little difference as im using dtim 1 in addition with 149 Chanel due homepod awdl issues (but i don't think this really make any difference) with iphone 12 pro max.

With ibf enabled i cant reach +A on any device.

Basic mixed WPA2/WPA3.

This test is from now:

In parallel i have two computers connected via wifi on teams meetings atm, so its still great result for me

1 Like

Added new version 2024.06.12_r26661_6.6.32_next-r2.4.mtk.rc2


  • adjusted airtime
  • enabled radar background
  • removed some not useful log
  • fix one small issue on ebf
  • fixed some compile warning
  • removed eth patches
  • twt can be enabled from LuCI (fixed to off by default)

TWT setting is on advanced tab


On the first post I have also added a guide for how to compile


Can you please better explain how you obtained such great result?


I tested multiple devices with many builds and with my iPhone 12 I always get disappointing speeds in the Bufferbloat tests, but gives the expected bandwidth. I don't give much importance to this, since this is a work device.

I think this will be the ultimate goal, but at the moment we are actively testing. so things have to settle.


The problem is that i dont have anything special and im sure is something related how ios manages the data flow in their browser.
I have made already dozen of tests with the new build and i still get A+ on safari:

But only A on chrome:

And i will repeat im using atm fully two laptos for teams meeting and spotify streaming performing these tests.
Important note is that the upload speed is much slower than on chrome…

I dont have any special configuration apart of already commented in previous thread.

WED is Off
IRQ off.
RPS on.
149 channel, dtim 1, 80mhz AX
Few older devices and homepod connected to 2.4, which is sniffing info all time.
No core tuning.
HFO on

Im not sure if this is placebo, but, 6 months ago i moved from ubiquiti ont to leox 010H-d prior using old f601 from zte. These all 3 devices have different bufferbloat results, the worst one is from ubiquiti nano g.


A new build again! :slightly_smiling_face:

Strong results (A’s) with new build.

Still had better latencies under load with “Test 2” build for some reason.

@auanasgheps thanks for the tip…seeing full bandwidth on speedtest rather than bufferbloat.

@Hoodwinks and @auanasgheps When testing wireless performance, especially for comparing one build to the next, you’re far better off running something like Crusader or Flent against a well-connected host on your local network.

It’s far too easy to conflate bandwidth/latency effects on wireless connectivity with issues that may actually be occurring between your edge device and ISP (and beyond).

I am always happy to see users getting excited about performance tests, but I put little weight on any Waveform or result when considering wireless tuning. Those tests are just too variable on top of an already variable wireless stack.

Please consider using Crusader for wireless testing going forward. :slightly_smiling_face:


Hey @pesa1234, glad to see this newest release with the airtime tweaks we’ve been testing! Could you help me understand what TWT is addressing and how I can help test it?

A simple definition is here:

Should help to save battery on wifi6 devices but you can see a performance drop

1 Like

One question:

Is it possible with crusader to check routing? Do you know if there's a public server.

Sorry for this stupid question but I wasn't able to get this info.

Now I'm working to:
1- Disable wed by default
2- Add wed setting on LuCi closer to offloading option on firewall

1 Like

No public servers that I'm aware of at this time. There could be some, but I'm not sure who/where they're published. For what it's worth, Crusader testing via wireless to a public endpoint would still introduce the same variables as I was calling out with Waveform/ that conflate testing wireless stack tweaks. But you may have been asking for other contexts :slight_smile:

Generally, for anyone wanting to help test and tune wireless "knobs", the test tools need to be able to run in a controlled manner that isolates the wireless stack (or at least minimizes any conflicting avenues of "noise", like adding an ISP/the general internet into testing figures).

Very cool! These will be very welcomed changes! Are you going to add a "notice" or "disclaimer" that enabling WED effectively negates the AQL path? That may help future users better understand they're really making a one-way-door tradeoff when enabling it?

You've piqued my curiosity here... there's been some long-standing advice in these forums that dtim_period '3' is the recommended interval for Apple-heavy environments. That advice was based on a recommendation produced by Apple itself and there is good technical detail about it here:

Have you found that dtim of 1 has addressed some other issue(s) in your environment?

Another interesting thing to me... I actually do the opposite with my four HomePods. I deny their association to 2.4Ghz, thus forcing them to 5Ghz. Were you finding an issue with your HomePod connecting to 5Ghz?

1 Like

Interesting, i will test dtim 3, as almost all devices in my house are from apple. Thank you.

The main issue with homepod is not related to dtim, is related to driver/AWDL: Homepod & ATV - Streaming Issues (MTK & MT76) - #3 by di_Niko

I am seeing this weirdness with my iPhone too. Sometimes it falls in the 2.4g speed range! I will never understand Apple products :slight_smile:

They use different servers so it make sense. Also, the "loaded" latency on Speedtest is always lower (better) than Waveform.

Yeah it makes sense but at the moment i can't: I'm not connecting other wired devices to the Flint. I believe my tests are "okay" because I run them multiple times and I usually get consistent results. But it makes sense to isolate external factors, sure.

I would love to see those changes! At the moment WED off is the better choiche, but having the option in LUCI would be great. And could become handy in the future if WED gets better.

1 Like