Flint 2 (GL-MT6000 ) - bug reports - collective thread

stable by which definition? I personally still had problems (spontanous extremely low speed, high latency and frozen connections) with the 5ghz network with the latest openwrt snapshot. The open source driver is still buggy. 4.5.7 is the only firmware with a stable wifi at the moment.

I’d wish people would take the openwrt native firmware talks outside of this thread…

5 Likes

There actually is an issue though. OpenWRT native firmware has a much newer code base than the OpenWRT base used by GL.iNet. I understand that GL.iNet cannot likely port their closed source elements every day, but this is a large part of the problem. Faults have been fixed in the latest OpenWRT code base that GL.iNet is not taking advantage of.

4 Likes

I also tried and failed at SQM. I don’t think you can load any packages on build v4.5.7. You can run scripts but not load any SW.

That‘s because the repo isn’t there yet and everything is still testing.

1 Like

A post was split to a new topic: Flint 2: PPPoE disconnects randomly

With firmware 4.5.7 i can confirm the 2.4ghz wifi is alot better.

Today i went out of my appartment which is the 5th elevation and went a few meters outside of the building, with the wrong firmware i had on the last stair only 1 bar.

But with the mediatek sdk i got around 3 to 4, similar as with the flint 1.

I did a speedtest:

Its okay that the speed and latency is not fast because its really far away, this should be kinda expected.

The only thing i did notice was that 5ghz was a little bit faster, but to be honest with the Flint 1 this signal was gone.

It looks really good :+1:

2 Likes

I can also confirm that the 2.4GHz range and speed has drastically improved with the MTK WiFi driver in the beta firmware. But the firmware seemed extremely buggy, even by beta standards.

  • If you try to adjust some WiFi settings it’ll create unknown interfaces (use iwinfo to list them).
  • The default transmit power is set to 100 in /etc/config/wireless, yet iwinfo ra0 info says that it’s 13 dBm. And it’s definitely not 13 dBm.
  • When using iwinfo ra0 info you’ll see that the hardware, offsets and encryption are all unknown.
  • You can’t change the country codes or transmit power via LuCI.
  • Network acceleration might not be working by default as LuCI says that SFO and HWO are disabled.
  • Some packages are missing or won’t install.
  • The router started crashing randomly when I set the same SSID for both radios.

The 2.4GHz range is probably better because the MTK driver is applying whatever it wants for the transmit power. But the speed could possibly be better because the MTK driver allows VHT rates for 802.11n via 2.4GHz and it also seems to be advertising beamforming capabilities.

I can’t verify the exact VHT capabilities since I forgot to check hostapd. And I really don’t want to reinstall the firmware, since I’m never going to stick with it due to the fact that that it downgrades you to OpenWrt 21.02.3 and all of the packages are out of date.

1 Like

The connection between the GL GUI, luci and the MTK driver isn’t completely done yet. It‘s more proof of concept than beta.

3 Likes

Yup you are right, i hope next version comes with the luci app for mtk sdk because i did saw this on other mediatek sdks, the country is set natively instead of OpenWrts, i guess for now the firmware is very basic to test for wifi :+1:

1 Like

Yeah. It seems more like a public alpha build at the moment, since beta software is typically more feature complete.

You might expect to have similar stability issues with the OpenWrt snapshots, since code changes within them on a daily basis. But so far they’ve been flawless for me in terms of stability.

It’d be an improvement, but for the future of the product I really hope they attempt to fix the issue within the mt76 driver.

If you’re still using 4.5.7 could you please share the output from cat /var/run/hostapd*.conf? Just be sure to mask your WiFi passwords.

that is strange I cannot find it :wink:

root@GL-MT6000:/tmp/run# ls
avahi-daemon                     dnsmasq.cfg01411c.br-guest.dhcp  rpcd                             usbmuxd
cloud                            dropbear.1.pid                   ubus                             usbmuxd.pid
config.md5                       fcgiwrap.socket                  udhcpc-br-ayaneo.pid             vsftpd
crond.pid                        fw3.state                        udhcpc-br-wlan0.pid              xtables.lock
dbus                             modem                            udhcpc-br-wlan1.pid
dbus.pid                         nginx.pid                        udhcpc-br-zigbee.pid
dnsmasq                          ngx-ubus-proxy.sock              udhcpc-eth1.pid

it must been somewhere else.

I’m gonna dig a little further I did found this:

root@GL-MT6000:/usr/share# cat wifi-features-mt798611 
{"phy":"ra0","max_txpwr":100,"hwmodes":{"b":true,"ax":true,"g":true,"n":true},"max_he":40}
root@GL-MT6000:/usr/share# cat wifi-features-mt798612
{"phy":"rax0","max_txpwr":100,"hwmodes":{"n":true,"a":true,"ac":true,"ax":true},"max_vht":160,"max_he":160}

but thats i think more of a dev file/metric than hostapds.

1 Like

It seems like the MTK driver doesn’t use hostapd and instead loads profiles from /etc/wireless/mediatek/.

I can see that mt7986.1.dat has TxPower=100 and CountryCode=US, but for me the country was set to DE by default. So it’s not going to be easy to compare this against the mt76 driver.

Anyway, this isn’t the place to discuss this stuff. But thanks for trying to help :grinning:

2 Likes

I’ve been monitoring the log files and realized that there’s a trend whenever my devices gets disconnect. Either of these would show. Any idea?

AP-STA-DISCONNECTED
deauthenticated due to inactivity (timer DEAUTH/REMOVE).

Known bug, exactly what we are talking since 1000 posts about.

So we will have to wait until this bug gets fixed.

Alright! Thank you! At least I’m not alone. And for those who managed to ‘solved’ the issue by flashing and other means… I’d not bang on that, given that the bug is independent of their ‘solution’.

I only noticed it with 4.5.7. Are you saying that the issue will still persist even if one downgrades to 4.5.4? So far, it only seems to affect my 5 GHz (80 MHz) connections. It’s getting annoying.

I encountered this issue since I am using the Flint 2 - so I would guess it’s a different reason.
It’s better on 80 MHz; but not completely gone.

I’ll try 4.5.4 again and see if the issue persists. Can I back up my configuration settings first and then restore it without any issues after I downgrade to 4.5.4 from 4.5.7 4.5.6?

EDIT: 4.5.6, not 4.5.7.

You can try it. Downgrading while keeping the settings is mostly not supported, but since there are just minor changes it should work.

If you encounter bugs, you will need to reset.

1 Like