Have 3 GL-MT1300 - spinned into goodcloud - all works great besides periodical hungs.
In the beginning it was only one unit in place where I live so rebooting it once a day wasn’t a problem. But now having the same with other (remote) device and it becomes a significant problem…
The unit doen’t repond to ping, ssh, not share DHCP, is completely frozen, nothing in logs (which are enabled BTW). All routers run on 3.2.0.3/3.2.0.1
I think I need to return to 3.2.0.0 - where it didn;t behave like this.
And found it. on Version 3.200 it also hungs - but it “unfreeze”. While on 3.201 and 3.203 it is compeltely stuck.
Have three sites - setup of each is:
1st site: ISP (fibre) modem with external IP → ethernet (NAT with DMZ and all ports forward) → MT1300 → switch (cisco SGP2000P) → rest of infra
2nd site: Huawei 5G modem with external IP set as bridge (direct external to roiuter) → 1g cable → MT1300 → cisco SGP3000
3rd site: LTE modem + neighbours wifi (for redundancy) → 3 links from router directly to server (only one) - 2 for host and 1 for IMM (it is IBM x3650 M4)
So from all sites I would expect the last one fail the most - while it is 1st and 2nd. Both upgraded.
Steps to recreate: just take transmission on linux → setup on unlimited → take 20x 20G torrents → start downloading
On 3.203 and 3.201 it hungs after minute, on 3.200 it is not. Seems that those higher versions handle badly large ammount of connections : that is area I would search for…
Unless somebody tell me how to dissasemble it and connect to internal GPIO (preasumebly there are) and debug it without loosing warranty
ps. wifi is disabled (using UI access points with Unifi network installed on UBNT server)
1 Like
I have a new firmware can you pls try?
A bit better - somtimes freeze only . Could you provide release notes/bug tracker for it (what extactly changed)?
As for me looks like dnsmasq is leaking and getting OS crashed.
GIving it a try now. I had been doing okay with the 0808 version in snapshots, and I’ve upgraded with the testing-with-5.1-driver from the testing folder.
I have the same problem with a GL_SF1200 using their wireguard client and keepsolid wireguard congiguration. I received this reply from tech support. I did this and it is working but it has been less than 24 hours. I will wait and see. I was told on another forum that it was a firmware bug. I do not see how this will work. Firmware is version 3.204.
On Mon, 23 Aug at 2:56 PM , GL.iNet Technical Support support@gl-inet.com wrote:
I never use keepsolid wireguard. Can you check if the router’s time is correct? Go to more settings->time zone. If the router’s time is different from your pc pls fix it. If the router has Internet, it should be able to sync with time server. But you may need to disconnect wireguard first to achieve this.
You can also remove the wireguard config from the router and set up again. Some vpn service providers has limitations in total number of config keys.
The testing-with-5.1-driver version was a little flakey operating on an ethernet WAN connection: with an ISP connection of 100/35 I was getting downloads of 12, 50, 5, 70, and all over the place. On wireless 2.4 connection (repeater) with a 100/100 ISP connection, I’m getting a pretty solid 55/55.
Sorry that that anecdotal experience isn’t more scientific; I’m traveling from hotel to hotel.
Going to try the new 0825 version now.
Hi ,
I have done a lot of tests on the stability of MT1300 in the last few days. In the process, I found a problem with the Ethernet driver of MT1300. I have fixed it, but I can’t confirm whether the stability reported by everyone is due to the Ethernet driver.
So far, I haven’t had a problem with device rebooting, except that Ethernet negotiation rates are too low to be usable.
I have no way to repeat the stability problem that everyone reported, so I cannot fix this problem, I need some help, I provide a special firmware in the link below, this firmware fixes the Ethernet driver problem and logs the system crash as much as possible in the event of a system crash.
https://dl.gl-inet.com/firmware/mt1300/testing/openwrt-mt1300-3.203-0826-oops-track.bin
When you notice that your device is rebooting, you first need to log in to the router via SSH and then execute the following command from the console
dd if=/dev/mtd7 of=/last.log
After the command is executed, you can copy last.log to your computer via SCP or some other tool, and then send the log to me via email or forum.
The above steps are a little complicated for ordinary users, if you have no experience at all, you can contact me for remote assistance.
1 Like
Hi
The problem is that at the time it hungs - there is no connectivity at all to device. It is frozen.
I can also confirm that negotation rates are a bit slow.
On one of my sites ISP provides gateway box for fibre - which in my setup working in DMZ + all port forward on MT1300 - but have wifi enabled. When it is frozen - I can see that negotated speed on this router is showing 10MB instead 1G. Yet - no connectivity untill rebooted.
Also - were trying to not use that ISP modem and use Huawei OTP device directly - but due to fact it required PPPoE and VLANing - hungs occured even more. So I presume it have to something to do with max number of conenction of etherenet driver …
Suggestion you are giving is the right one: deumping the kernel / cores /logs - but we sure ain’t gonna receive it when system os frozen…
My suggestion is that you redirect log writing to USB device or add tunning attribute that can be specified elsewhere… so that logs can be reviewed after router restart/hungs.
I can confirm that the firmware above solves the Ethernet negotiation rate of 10M, you can try it
Sure. Will try.
One thing: you should really place a release notes for each version somewhere
It still hungs once in a while (once a day) on openwrt-mt1300-3.203-0826-oops-track.bin. No response via web interface/ssh
Can you check if you can get the log using above command?
4>[ 3499.512485] —[ end trace cc44022468960fd3 ]—
<0>[ 3499.521024] Kernel panic - not syncing: Fatal exception
Thank you for your log, your device is always hanging, did not auto reboot, right?
Hmmm. From kernel trace looks like NewZeland site is getting this started… That one is not on gl.INET (goodCloud) - 3 are in Poland and now we have 4th in UK
IPv6: ADDRCONF(NETDEV_UP): NewZelan: link is not ready
<4>[ 2663.446029] Unhandled kernel unaligned access
Will check (by disabling ipv6) on it
