GL.iNET Flint 2 (GL-MT6000) discussions

For this hardware, I personally recommend a snapshot since it is relatively new. They (snapshots) have been really stable for me and you will likely benefit from active development rather than waiting for various features/fixes to get backported to a tagged release. That said, I have not tried the firmware on this just yet. I have on my Redmi AX6000 which uses the same chipset/drivers without any issues.

2 Likes

I recently replaced my Banana R3 wifirouter and my 2 Belkin RT3200 access points with 3 MT6000 and I really, really like them. Installing OpenWrt is extremely easy: you can flash snapshot directly from the vendors firmware. I perceive MT6000 snapshot at least as stable as the 23.05.4 on the RT3200/R3. I was fed up with the bootloader issues on the RT3200 and the inflexibility of the R3 (flashing a new version of OpenWrt is a bit more complex) and the eMMC memory which by default only has a very small partition available.

Speed and range are better. And I now have more time for other open source initiatives (Home Assistant and Lyrion Music Server in my case).

3 Likes

Agree snapshots are the way to go it's what I run too, but I'd wait a few days before switching over. The mt76 commit nbd did today has a new firmware for our mt7986, nice tweaks but let it get tested a little. This target is in fantastic shape imo.

4 Likes

I've only used it on 23.05.x but others are using it on master SNAPSHOT as well.

Unless you've got a problem that a newer firmware fixes, stick with whatever firmware OpenWrt defaults to. I was just playing with bleeding edge firmware for fun. :roll_eyes: :stuck_out_tongue_winking_eye:

1 Like

hi all!

although i live in qualcomm qca land (3x ipq8074 devices here)... i did own 3 of these mt6000s a few months back before returning them.

just fyi im fairly apt in all this and was running the latest snapshots at the time self compiling etc etc etc. yes i tried the latest stable at the time as well. i spent a good chunk of time trying to resolve this before sending them back to amazon.

i was wondering if this issue has been resolved:

when a station with smps enabled would go to sleep and switch smps to static (eg: 1 antenna only), on wake up the station would send a signal back to the ap requesting smps dynamic (eg: 2 antennas please!) but the ap (the mt6000 in this case) would not respect this request and thus, throughput would be 1/2 (i found it to be even lower... 300mbit tx or rx @ 160mhz) of what it should be.

i don't have a flurry of 5g 160mhz clients to test, but i had this happen with my ax211 based laptop running win 10. i could repeat this behavior at will. suspend win10, wake and presto it would happen.

a last fyi, you may be asking why not just disable smps in the intell advanced properties on the station... of course i did that but due to the fact that intel drivers are a bit garbage every once in a while it would ignore whatever it was st to the (SMPS off) and would still use smps.

is anyone still expericing this on the mt6000 or any other mt7___ chipsets even with all the recent commits?

edit : before we go (probably rightfully so...) blaming the intel station drivers... just fyi, i DO NOT experience any such behavior on my ipq8074 based devices... so clearly something is being handled better(?) with my qca access points.

1 Like

I have the same chipset on my corp laptop and never had this problem…

Has anyone noticed any weird behaviour since the SNAPSHOT r27229-ebe7c5f1a3? After switching to that version, I didn't get IP on the WAN interface. I had to unplug/plug cabling to re-trigger DHCP.

Also got a kernel panic:

[60067.863413] ------------[ cut here ]------------
[60067.868034] phy_check_link_status+0x0/0xc0: returned: -110
[60067.873553] WARNING: CPU: 1 PID: 1046 at phy_state_machine+0x90/0x28c
[60067.879981] Modules linked in: pppoe ppp_async nft_fib_inet nf_flow_table_inet wireguard rndis_host pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack_netlink nf_conntrack mt7915e(O) mt76_connac_lib(O) mt76(O) mac80211(O) libchacha20poly1305 iptable_mangle iptable_filter ipt_REJECT ipt_ECN ip_tables chacha_neon cfg80211(O) cdc_ether xt_time xt_tcpudp xt_tcpmss xt_statistic xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_comment xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY x_tables usbnet slhc sch_cake poly1305_neon nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 libcurve25519_generic libcrc32c libchacha ipheth compat(O) crypto_safexcel sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit
[60067.880154]  act_mirred act_gact ifb ip6_udp_tunnel udp_tunnel tun sha512_arm64 sha1_ce sha1_generic seqiv md5 geniv des_generic libdes authencesn authenc leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd fsl_mph_dr_of ehci_platform ehci_fsl ehci_hcd gpio_button_hotplug(O) usbcore usb_common aquantia mii
[60067.997212] CPU: 1 PID: 1046 Comm: kworker/u8:2 Tainted: G           O       6.6.47 #0
[60068.005108] Hardware name: GL.iNet GL-MT6000 (DT)
[60068.009795] Workqueue: events_power_efficient phy_state_machine
[60068.015705] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[60068.022646] pc : phy_state_machine+0x90/0x28c
[60068.026988] lr : phy_state_machine+0x90/0x28c
[60068.031329] sp : ffffffc085753d50
[60068.034627] x29: ffffffc085753d50 x28: 0000000000000000 x27: 61c8864680b583eb
[60068.041743] x26: ffffff8000011028 x25: ffffff8006d2db00 x24: ffffff8000017405
[60068.048859] x23: 00000000ffffff92 x22: 0000000000000006 x21: ffffff8000271490
[60068.055975] x20: ffffff80002714e8 x19: ffffff8000271000 x18: 00000000000001db
[60068.063090] x17: 0000000000000000 x16: 0000000000000000 x15: ffffffc080bda1e8
[60068.070206] x14: 0000000000000591 x13: 00000000000001db x12: 00000000ffffffea
[60068.077321] x11: 00000000ffffefff x10: ffffffc080c321e8 x9 : ffffffc080bda190
[60068.084436] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001
[60068.091551] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[60068.098667] x2 : ffffff803fd9c490 x1 : ffffffbfbf1e9000 x0 : 000000000000002e
[60068.105783] Call trace:
[60068.108215]  phy_state_machine+0x90/0x28c
[60068.112212]  process_one_work+0x174/0x2cc
[60068.116210]  worker_thread+0x2e8/0x4d0
[60068.119944]  kthread+0xd8/0xdc
[60068.122986]  ret_from_fork+0x10/0x20
[60068.126548] ---[ end trace 0000000000000000 ]---
3 Likes

Yes. Here also.
It started for me at 27208.
Related to new driver series it seems.
Rebooting cable modem once clears it.

Same here, I had to roll back. That build is unusable if you have DHCP from your ISP. Restarting the ONT had no effect. I'm waiting for a new snapshot build.

Update: I tried that build again and unplugging and then connecting the WAN connection does bring up Internet connectivity.

160MHz is a bit odd in 5Ghz, as it does have to use DFS in many regions.

What happens when you do the 80MHz channels in a non-DFS band?

For who have issues on latest snapshot can you try my testing build?

I compiled testing version without this commit https://github.com/pesa1234/openwrt/commit/1069514978c419cc5bdfc18c5670b46d0443a686 for who have issues on wan

4 Likes

That commit is by @daniel have either of you reported it?

No, I would like to be sure that is that one that cause the issue.

I don't get the issue, so I can't test it by myself I need one that have the issue

2 Likes

I am not having the WAN issue with that build. Thank you for creating it.

It works! Thank you.

1 Like

So I open a bug report on openwrt thanks for cooperation guys

Done! https://github.com/openwrt/openwrt/issues/16281

Thanks guys for sharing info!

10 Likes

I swear pesa is one of the main reasons you should get a GL-MT6000

8 Likes

I added a comment to the bug, and also mentioned that the cable-reconnect trick seems to work for me.

7 Likes

Has anyone tried it with the commits added to mt76 yet? The mt7986 firmware update was added there by nbd a few days ago. Looks like it's not added to main branch yet so it wouldn't be in the snapshot.

1 Like

There are only two commits in the mt76 repo that aren't yet in master. See here and here. So that last few snapshots include the new firmware.

2 Likes