Yes, country code is set accordingly. AP's were on 120-124-128 DFS channels, also known as weather radar channels. As of today I've changed over to 55-60-64. Lets wait and see if the dropouts will occur again
Speculating here. What if the radar detection is broken and it considers WiFi from the other AP as radar. Switching to non-DFS could help. At least switching the main AP so that dumb AP doesn’t take it as a radar.
Don’t think so, at least for the most commonly used DFS channels up to 80 MHz. It has worked very good for me, so I think has something to do with me jumping too fast to a new snapshot. I just have to cope with the bad and the good it brings with. I’m not too experienced on this things so I leave granular troubleshooting to the experts here. The 36 to 48 channel spectrum is very crowded here, besides, I want to use the 80 MHz bandwidth. It’s faster.
Hey all!
Just dropping an update here to mention that I have been on a very, very stable build/config at the following:
# cat /etc/os-release | grep BUILD_ID
BUILD_ID="r26348-3e5a23639f"
# uptime
13:17:42 up 5 days, 20:10, load average: 0.05, 0.03, 0.00
# dmesg | grep Firmware
[ 11.707186] platform 15010000.wed: MTK WED WO Firmware Version: DEV_000000, Build Time: 20240507160523
[ 12.355218] mt798x-wmac 18000000.wifi: WM Firmware Version: ____000000, Build Time: 20240507160318
[ 12.439591] mt798x-wmac 18000000.wifi: WA Firmware Version: DEV_000000, Build Time: 20240507160509
# cat /sys/module/mt7915e/parameters/wed_enable
Y
# service irqbalance status
inactive
# service firewall status
inactive
# service bridger status
running
I have had zero mt76 timeout errors/crashes in this uptime thus far (!!!)
Since this firmware is newer with bug fixes and has been tested successfully for ~6 months, what do you think about just PR it into OpenWrt so it's included by default?
Btw I added a new section to our wiki so we document it there too: [https://openwrt.org/toh/gl.inet/gl-mt6000#replacing_the_firmware]
I've been testing the mt7915 firmware as well and it's also been solid.
mt7915e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240429200716a
mt7915e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240429200752
mt7915e 0000:01:00.0: WA Firmware Version: DEV_000000, Build Time: 20240429200812
This is not the most recent.
For mt7915? Which/where is the most recent then? Thank you.
See here: GL.iNET Flint 2 (GL-MT6000) Snapshot / Experimental / Bleeding Edge - #2 by _FailSafe
Also may be helpful: GL.iNET Flint 2 (GL-MT6000) Snapshot / Experimental / Bleeding Edge - #10 by _FailSafe
That's for mt7986. The mt7915 firmware is also included in the feed which has the 20240429 date stamp vs. 20240507 for mt7986.
I know this is a great target but thinking we have too many threads open
Which device are you putting the mt7915 firmware onto?
Agreed. I never think to come to this thread and just stick to the main.
@phinn, @SiXX, @enmaskarado, @dave14305, I hear you... But from what I've seen, my opinion is there are three distinct camps of OpenWrt users:
- OpenWrt Consumer:
Someone who knows enough to have found OpenWrt and has built up confidence to follow an existing trail (read: guide) on loading OpenWrt on their device X. This type of user typically values something better than OEM, but generally prefers stability for any number of reasons. - OpenWrt Hobbyist/Tinkerer:
One who pursues OpenWrt with a passion to really get into the weeds of what their device(s) is capable of and isn't afraid to get their hands a little (or a lot) dirty. This type likes to not just find the "knobs", but to start twisting and turning them too. Sometimes this results in instability/crashes/dragons that may require extreme measures to correct (bootloader type stuff). But they enjoy the ride and are willing to sacrifice some stability/uptime for the sake of this enjoyment (or passion). - OpenWrt Developer:
This really doesn't need a lot of definition. This is the type of individual who most of us hobbyists wish we could be in our dreams. They typically are found to be more active directly in Github (or their respective git repos).
So from where I was sitting a few weeks back when I created this thread, it seemed some of us (I'll stick my hand up in the air
) were posting some "hobbyist" level stuff in the main thread and I presumed (based on some posts I saw) that some Snapshot-level issues we were posting about were causing angst among the "OpenWrt Consumer" bunch who were very concerned about stability.
In order to not give new (or potential) MT6000 owners bad vibes about the device they just purchased, I thought moving the "hobbyist/developer" type dialog over here would free up the main thread to be a more stable, happy place for the general MT6000 consumer.
If you feel this thread is not needed and want to see this dialogue moved over to the main thread, I can close this one. But there has to be a place for the higher-level OpenWrt users to converse about possibly unstable things, wherever you feel that best fits
Agree on your take. For now it seems we have the 3 since pesa is doing a nice build many people are using and new firmware revs too. I'd also be fine moving this convo to the main thread and just linking the wiki at the top to point new users there for quick reading first. Or hopefully when things cool off we drop this one (or when a Filogic 880 / wifi 7 target hits ).
Did anyone run a build with GCC 13.3 yet? I see they switched to it. I will within the next couple days. It's just a bugfix update but curious.
Just pushed up another update to this script to account for some issues as noted by @gassan. It also can be run directly on an OpenWrt device now as it will use /tmp
as the base directory in that case.
I'm good with that too if that's the consensus here! What do you think, @SiXX, @enmaskarado, @dave14305 ?
I support this 100%.
I’m here to learn, no matter the thread. I just kept getting confused where to find the coolest info.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.