Flint2 MT6000 Reboots under load on 5Ghz

Routers
1

Hi

MT6000 running v4.6.2 currently.
I had previously used a Flint AX1800 (now an extender)
and I also have a BerylAX MT3000.
I've been using Openwrt from the early days, and run an IOT LAN
similar to the guest network config.

I've been battling a crash problem since upgrading from v4.5.6.
When I first upgraded to v4.5.7, the router would boot loop every 2 minutes.
I reverted to v4.5.6. When v4.5.8 came out, I had the same behaviour, and reverted to v4.5.6.
I saw comments in the forum saying v4.5.8 was stable for a lot of people, and
when v.4.6.2 came out I tried again. Similar behaviour, reboots with minutes of the WiFi
being availble to clients.

I had tried factory resets and wiping all config and doing the minimum config to try
and work out what might at fault, and eventually got things mostly stable by using the uboot
method to get a factory default clean install. After a lot more testing of combinations, I've
narrowed down the issue to using 5Ghz.

I have had 14 days of stability when using 2.4Ghz only.
I have also had 24hrs of enabling 5GHz, but not letting any clients connect (unique ssid).

I can get the router to crash in seconds by connecting one phone to 5GHz
and kicking off a smb file transfer (phone <-> nas).

I don't see a crash.log after the reboot, but I set up a separate syslog server
to try and see what's going on at the point of the crash.
I have some kern.log entries but I suspect the event that crashes is not making it over.

Any suggestions on what to look for or how to preserve the crash.log ?

2

can you open one terminal window and check with htop what is happening?

my issue is the way you try to replicate it, does this also happen without the smb transfer on 5ghz?

the difficulty with SMB is that it is utilising alot of cpu but can also cache ram, maybe it need to be priortized lower or there need to be a limit set how many resources that process can have otherwise indeed normal process on the router can get halted, but that is also kind of expected.

would been nice if you can show the output of htop :wink:

3

Well, the same smb transfer works fine over 2.4Ghz.
I should say the smb server is a freebsd nas box on the wired lan,
not samba on the router.

I just had the router crash with only a single client connected to 5Ghz.

I had left my phone connected as the only client on 5Ghz, with everything
else on 2.4Ghz, when the cry went out "Is the internet down?".
The router was rebooting. It's a bit more unpredictable with only light traffic.
However, if I put multiple devices on 5Ghz, it will crash in a few minutes.

I switched 5Ghz off again, as I can't take everyone's internet down during
the day. I only get to experiment when no one is online.

I have htop installed as well as iftop.

This the config:

root@core:~# cat /etc/config/wireless

config wifi-device 'mt798611'
option type 'mtk'
option band '2g'
option htmode 'HE40'
option channel 'auto'
option random_bssid '1'
option legacy_rates '0'
option hwmode '11g'
option txpower '100'
option country 'GB'

config wifi-iface 'wifi2g'
option device 'mt798611'
option mode 'ap'
option network 'lan'
option ifname 'ra0'
option wds '1'
option ieee80211k '1'
option bss_transition '1'
option key 'mypw'
option ssid 'my2g'
option encryption 'sae-mixed'
option macaddr '46:90:54:50:5E:81'

config wifi-device 'mt798612'
option type 'mtk'
option band '5g'
option channel 'auto'
option htmode 'HE80'
option txpower '100'
option legacy_rates '0'
option hwmode '11a'
option country 'GB'
option random_bssid '0'

config wifi-iface 'wifi5g'
option device 'mt798612'
option network 'lan'
option mode 'ap'
option ifname 'rax0'
option wds '1'
option key 'mypw'
option encryption 'sae-mixed'
option ssid 'my5g'
option hidden '0'
option disabled '1'

config wifi-iface 'guest2g'
option device 'mt798611'
option network 'guest'
option mode 'ap'
option ifname 'ra1'
option encryption 'psk2'
option key 'goodlife'
option ssid 'GL-MT6000-cfb-Guest'
option guest '1'
option wds '1'
option isolate '1'
option disabled '1'
option macaddr 'EE:93:4D:34:85:86'

config wifi-iface 'guest5g'
option device 'mt798612'
option network 'guest'
option mode 'ap'
option ifname 'rax1'
option encryption 'psk2'
option key 'goodlife'
option ssid 'GL-MT6000-cfb-5G-Guest'
option guest '1'
option wds '1'
option isolate '1'
option disabled '1'

config wifi-iface 'smarthome'
option device 'mt798611'
option mode 'ap'
option ifname 'ra2'
option network 'smarthome'
option ssid 'iot'
option key 'mypw'
option isolate '1'
option encryption 'psk-mixed'
option hidden '0'
option macaddr 'B2:53:F0:xx:xx:xx'

4

May I know does the router use the attached power supply?

6

If you don't have problem in 4.5.6, which is using open source wifi driver, Pls try the op24 firmware

https://dl.gl-inet.com/router/mt6000/

7

May I know does the router use the attached power supply?

Actually, in this case no.
I use a 12V 4A "brick" switching PSU.
I have used this for several years, from when I had both a dsl modem and wifi router running in parallel from the same 12V source.

I also used the same combination for the last 3 main wifi routers, including the Flint AX1800.
The MT6000 was also using the same method, when I first got it.until I switched to a fibre
ONT on it's own PSU in January.

The MT6000 has the 4A PSU all to itself, but swapping to the OEM one should be an easy test
to replicate later.

8

I will try that once I can get a "maintenance window" :wink:

9

I switched the PSU to the OEM one, and while I've only been running for around 24hrs,
it seems more stable. However, I was able to cause a crash by doing the file copy from the
nas to the phone over 5GHz. I was able to leave 5G enabled with one device for a few
hours without a crash, which is why I think things might be more stable than before.

The power lead on the OEM plug is just slightly too short to reach the router, which I
think was part of the reason I started using the other PSU all these years ago.

I wonder is the later firmware causing a higher power drain than the earlier one?

I can't get much testing done at the minute due to everyone else in the household
kicking up a fuss everytime the router/internet goes down :frowning:

10

Probably the 5GHz devices is more than before, and the client devices distance is longer than before, so it consume more power.

11

Hi,

Just an update to say that I finally switched over to 4.6.4-op42.
It's been just over three weeks and for the most part stable.
I've also gone back to using my 4A power brick with a longer cable.

I have had two mysterious incidents where in one case all wifi stopped.
I was able to ssh in over lan and reboot the router.
The other case was a few wifi devices dropped off the network and
wouldn't reconnect. Again a reboot seemed to cure that.

So for me, op24 seems significantly more stable.

12

4.6.6-op24 is so far the most stable firmware version for the GL-MT6000 that I have used and I am putting it under a lot of testing pressure here. Credit to the development team and hope that they will continue to build on its success without going when one step forwards and two steps back.

13

Great that it works for you. Note that most of credit is due to OpenWrt and upstream contributors.

15

I'm running this now.
I'm waiting to see if I get that weird "no wifi" thing again.
It occurred twice in three weeks with 4.6.4-op24.

16

Hi

I'm resurrecting this old thread as I want to follow up.

I ran openwrt-mt6000-4.6.6-op24 for a while and for the
most part it has been stable.

Whenever there has been a release of the stock firmware,
I try it, but the router crashes within minutes of booting
as clients connect.

I've been on 4.7.0-op24 for the last while to maintain some
level of uptime, but this week I tried running on stock 4.7.7.
I can get about 8 hours before it crashes.

I'd really like to get to the bottom of this.
The crash log is always empty after the reboot.

I had a (remote) syslog server running for a while to try and catch
the last log output before a crash and would like some tips
on what I should be looking for in the logs.

17

Sounds like a heat issue, I know it’s a warranty issue but you could check the heatsink. Logs blank point me to a hardware issue. Fan on top maybe as a test? Maybe one of the 5g radio chip isn’t making contact with the heatsink?

20

Would you mind sharing the logs you've captured? We can take a closer look together to see if there are any other anomalies that might need attention.

21

I will. Been busy with work last day or so.

I'm trying to see if I am getting the logs to syslog server at up to the point of crashing.
I can force a crash by doing a file transfer between my NAS and phone.

I'll give more details once I capture the logs.

22

Hi

Can you tell me which log lines make the most sense to share?
I don't want to share too much on a public forum, nor post irrelevent logs.

I have post crash boot logs, which don't seem to show much other than what you
would expect to see in system.log and kernel.log on boot.

I was able to force a crash late last night by transferring files, but unfortunately
non of the logging was going to my syslog server as it seems on first boot
/etc/resolv.conf points to external servers, and therefore the router can't
resolve my internal syslog host.
If I disable adguard, resolv.conf changes to 127.0.0.1
and logging starts working again, but a reboot defaults back to external.

I tried to force a crash early this morning before everyone else was awake and
using their gadgets, and I couldn't get it to crash on demand even with the file
transfer method. It doesn't crash overnight either as the demand for wifi drops off
when everyone is sleeping.
So I am swaying to idea that it might be heat and power related.

It's worth noting that the op24 firmware doesn't seem to trigger the crash.

I will keep trying to catch it in the act and grab the logs.

23

Sorry for the late reply. You can SSH into the device and run the following command to store logs:
logread -f > /root/sys.log &

This will continuously save the system logs to the sys.log file in the /root directory. Even if the device crashes and reboots, the logs recorded before the crash will still be preserved. After the reboot, you can use a tool like WinSCP to retrieve the sys.log file.

When reviewing the logs, pay attention to:

  • Any messages that appear to be flooding repeatedly

  • Log entries with err (error) or warn (warning) level

  • Any entries containing keywords like CPU 0, panic, or watchdog, as these may indicate serious system issues.

1 Like
24

No worries.
I don't get time to debug routers a lot either :wink:

logread -f > /root/sys.log &

I should have thought of that.
I have a sd card mounted too that I can use for a while,
though I burned one out years ago on openwrt and too many writes.

An update:
While trying to rule in and out causes, I renamed the 5Ghz SSID to
a name that only my phone would connect to, and none of the other
devices at home are configured for.

OpenWrt 21.02-SNAPSHOT, r15812+1085-46b6ee7ffc
 -----------------------------------------------------
root@core:~# cat /etc/glversion
4.7.7
root@core:~# uptime
 22:43:24 up 1 day, 11:05,  load average: 0.00, 0.01, 0.00

Longest uptime prior to that was about 8hrs.
Though I've noticed my phone can flip over to the 2.4Ghz SSID,
meaning nothing is on 5Ghz for a period of time.

From the uptime so far, I am guessing that the workload on 5Ghz
is likely playing a part in the crashes.
If it doesn't crash in the next day or so, I'll undo the 5Ghz SSID change
and put the rest of the devices back onto it.

I also used luci to set default /etc/resolv.conf to 127.0.0.1
which helps with the remote syslog.