Since that's a generic patch for all chips, couldn't you just remove it? It doesn't benefit us at all as it just makes all connected devices use the much worse 2.4 GHz radio for 10 minutes. And maybe it also screws with zero wait DFS?
It's important to remember that some of these patches have existed for years, but there are likely good reasons why Felix hasn't merged them.
In order to better keep this thread on-topic, I moved my previous post here: GL.iNet GL-MT6000 - AQL and WiFi Latency - #18 by _FailSafe
Sorry for delay...
to add iBF and VHT you need to import patches from my repo and compile mac80211 hostapd iwinfo and mt76 or flash my building.
To check by command line...
root@MT6000:~# hostapd_cli -i phy0-ap0 get_ibf
ibf_enable: 1
To enable iBF by command line iBF:
uci set wireless.radio0.itxbfen='1'
uci set wireless.radio1.itxbfen='1'
uci commit
wifi restart
To enable VHT
uci set wireless.radio0.vendor_vht='1'
uci commit
wifi restart
I didn't understand where, from what I read from code it is changed from 1 to 10 minutes. Maybe I'll decrease that time in future
From what I have see, most of them are updated regularly from mtk.
This specific patch hasn't been updated in over 2 years, and Felix hasn't merged it in all that time. So it's probably safe to assume that he avoided it because there's literally no benefit to it. It just makes you wait much longer for your 5 GHz radio to be up and running.
Thank you. How do you verify if VHT on 2g is active/working?
last time update of that patch is Wed Jul 12 23:08:27 2023 +0800
This means that is available on device
iwinfo phy0 htmode
HT20 HT40 VHT20 VHT40 HE20 HE40
to understand if a device use it
iwinfo phy0-ap0 assoclist
you should see VHT-xxx
Yeah, there's been minor adjustments to it. But what I'm saying is that the patch has existed since Tue, 29 Mar 2022 16:06:30 +0800 and it seems as though Felix has avoided merging all versions of it because there's no benefits to it. Like, who wants to wait 10 minutes for their WiFi to start working when the standard OpenWrt version will be up and running within 60 seconds?
If you reboot the router every 10 minutes could be an issue 
Sure, but with your "optimized" firmware the 5 GHz radio is now 10 times slower at boot when compared to a stock OpenWrt snapshot. So that doesn't benefit anyone that uses DFS channels.
you definitely configured it wrong... try again, come on. 
With this firmware installed use a DFS channel (e.g. 120) and then reboot your router. It'll now take 10 minutes for the 5 GHz radio to be up and running, since that's what the patch changes.
What you write makes no sense.... This build is great like this!
If you don't like it... Create your own build or go back to fw stock.
If you want I can prepare a build without that patch, can you test if dfs is working good?
I suggest you read through what's already been said, since I didn't say anything about the WiFi speed. And I'm not criticizing the firmware either. I just figured I'd mention that a certain patch has no benefits to people like you or me, so if @pesa1234 were to remove it then the 5 GHz radio would start as quickly as it does with a stock OpenWrt snapshot.
@pesa1234 Sure, I'd give it a quick test if you build it
We need to check if the DFS works. Maybe tomorrow I'll send it by PM to you. Thanks
Thanks again. How about eBF is it available?
If you don't enable iBF yes, as standard
Ok so eBF is always enabled by default, does enabling iBF disable eBF?