GL.iNET Flint 2 (GL-MT6000) Snapshot / Experimental / Bleeding Edge

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

1 Like

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.

1 Like

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 (!!!) :slight_smile:

8 Likes