GL.iNET Flint 2 (GL-MT6000) discussions

I noticed that OEM U-Boot Recovery doesn't work if PC is connected to WAN or LAN1 ports (RTL8221B). Recovery only works if PC is connected to one of the other LAN ports (LAN2 to LAN5, MT7531AE). Can someone please update the wiki page https://openwrt.org/toh/gl.inet/gl-mt6000 ? Thanks in advance.

This lead me to this observation about this device:

According to https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=fe10f9743935d6986e80e7cb082469e6bc5a03f0 , there are two 2.5 Gbps RTL8221B ports (WAN and LAN1) on this device.

However only one 2.5 Gbps RTL8221B port (WAN) port is defined as independent port (eth1) (i.e. not part of DSA) in https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/mediatek/dts/mt7986a-glinet-gl-mt6000.dts .

The other 2.5 Gbps RTL8221B port (LAN1) is defined as part of the DSA group (eth0) along with the rest of the four 1 Gbps (MT7531AE) ports.

Shouldn't LAN1 port be outside of the DSA group (eth0) and separate (like WAN port which is eth1)?

noticed that OEM U-Boot Recovery doesn't work if PC is connected to WAN or LAN1 ports (RTL8221B). Recovery only works if PC is connected to one of the other LAN ports (LAN2 to LAN5, MT7531AE).

Is this true with a current (11-Aug-24) snapshot?

This is in the OEM U-Boot Recovery interface. Not related to any specific OpenWrt version.

2 Likes

Highly recommend you update the wiki page if what you’re saying is true. Could be useful to a lot of people.

If you don’t have an account go ahead and type in the thread, the verbiage you would like, and I will paste it in there for you.

What are you asking for here the wiki already says: "Connect an ethernet cable from a LAN port of the MT6000 to the ethernet port of your computer." this seems accurate to me. Meanwhile the Gl-inet recovery page says it can be either LAN or WAN port.

It won't work with LAN1 (2.5 Gbps) port of MT6000. However any of the LAN2 to LAN5 (1 Gbps) ports work fine for OEM U-Boot Recovery.

3 Likes

Any comments on this?

I also require that. In case of building snapshot, which packages should I not choose so that wifi drivers are absent?

Open a new thread

@tcp @logi this is a MediaTek SoC based device which uses mt76 driver for wifi. So just go to Firmware Selector, enter device, pick stable or snapshot, click the Customize dropdown, remove "kmod-mt7915e", then select request build. You'll get a build without the driver that way. Once your're flashed and running go into LuCI > Network > Wireless and make sure everything is removed too.

edit: I should note there may still be some power to the radios even with the driver removed, this might require a custom kernel or more likely a hardware modification to power off completely.

3 Likes

I also noticed this weeks ago. I cannot access U-Boot with 2.5G ports (not sure if the WAN/LAN one work). The 1G ports work fine.

1 Like

Hello - just thought I would post here that while SNAPSHOT r27160 looks to contain some nice mediatek updates it breaks my basic mesh configuration. The mesh node connects but only at 20Mhz 6.0Mbps with no data being passed thru.

I had to revert to a prior build to get mesh working again.

1 Like

I've read that this was fixed in today's snapshot.

Doubtful. r27160 would be this commit, which is the latest commit as of right now. I'm running r27159, which is one commit prior. Could be the mt76 updates introduced a regression?

1 Like

It might be just me, but on a Ziply 2G up/down fiber I can't get past 1.3Gbps up/down with MT6000 and a vanilla OpenWRT 23.05.4 on top.

The router is connected to the ONT with the proper grade cable on the 2.5G WAN port, I tried speedtesting directly from the router and from a machine wired into the LAN 2.5G port, same thing. Tried enabling/disabling sw/hw flow offloading and that didn't make a difference either.

I honestly suspected Ziply but the Zyxel they gave me pushes 2G up/down no issue, with the same exact cabling setup (and this isn't even me testing from the router itself, just from a wired laptop). Again, it may totally be me, and I hope someone points out something obviously wrong here, but it is vanilla OpenWRT so I'm not sure what I could be doing wrong.

CPU usage doesn't go above 30-40% during the speedtests, is it just not using multiple cores or something? At the edge of my technical knowledge here.

Yes - the latest driver updates included seem to break certain functionalities. My apple homekit system was completely taken out… had to revert back to previous build until I can troubleshoot.

2 Likes

@vw-ort and @SiXX : I don't see any issues entered yet on mesh or apple homekit problems on latest mt76 update. It's working in my simpler set-up, but worth giving @nbd a ping or opening an issue if he is not already aware.

2 Likes

Thanks for the link. I reported the issue.

1 Like

Yeah, there seems something not working OK in latest snapshot (27160).
I can't even ping certain clients (doorbell, camera), although some are connected and seen by applications.

Edit: Seems like all wireless clients won't react to a ping

Agreed - it’s multicast that’s broken. Toggling multicast -to- unicast ON in WiFi settings brought my apple HomeKit back online (outdoor cams, doorbell, thermostat, etc).

1 Like