Another huge bug in 23.05.5 for GL.iNET MT3000 (Router keeps rebooting)

Installing and Using OpenWrt
1

Today I flashed the latest 23.05.5 - clean flash with no settings or anythign else retained. Then set up wifi and wireguard, everything was working perfectly.

I powered the router off and went about some other things, before powering it back on a couple of hours later and connecting via laptop.

It connected fine and my google homepage opened, but as soon as I try to use any data - the router crashes and reboots. This happens repeatedly, over and over.

After the reboot, I can connect again and access luci without issue, but, if I:

  • update lists in the software tab, it succeeds - but then causes the device to crash and reboot (every single time)
  • try to load a web page with more content than google it such as Youtube - it crashes and reboots (every single time)

Any attempt to use data crashes the router and causes it to reboot.

I can stay connected via wifi indefinitely, but as soon as I try to download anything or use data... poof... the router crashes and reboots.

This also happened on the previous 23.05.5 snapshot, I hoped it would be resolved in the official release, but it is not.

Does anyone know anything about this issue?

Additional Note: This does not happen when connected via ethernet - only wifi causes the crash

2

Had you installed any additional packages?

Let’s see your config

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
3

Maybe provide something useful like the actual dump of the crash log.

4

Where is the log located?... It's lost on reboot...

5

Only luci-proto-wireguard and dependencies, nothing else.

I'm currently connected via ethernet and there is no such issue. I can browse, download, update package lists, anything with no crash - so it's caused by wifi only - deifnitely another crippling wifi bug.

Here's the output from the commands:

ubus call system board
{
	"kernel": "5.15.167",
	"hostname": "EDITNet",
	"system": "ARMv8 Processor rev 4",
	"model": "GL.iNet GL-MT3000",
	"board_name": "glinet,gl-mt3000",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "23.05.5",
		"revision": "r24106-10cc5fcd00",
		"target": "mediatek/filogic",
		"description": "OpenWrt 23.05.5 r24106-10cc5fcd00"
	}
}

root@EDIT:~# cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'
	option ip6assign '0'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth1'
	option ip6assign '0'
	option ipv6 '0'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option delegate '0'
	option ip6assign '0'

config interface 'wan'
	option device 'eth0'
	option proto 'dhcp'
	option delegate '0'
	option ip6assign '0'

config interface 'WGINTERFACE'
	option proto 'wireguard'
	option private_key 'EDIT'
	list addresses 'EDIT'
	option force_link '1'
	option delegate '0'
	option ip6assign '0'

config wireguard_WGINTERFACE
	option public_key 'EDIT'
	list allowed_ips '0.0.0.0/0'
	option route_allowed_ips '1'
	option endpoint_host 'EDIT'
	option endpoint_port '51820'
	option ip6assign '0'

config device
	option name 'eth0'
	option ipv6 '0'

config device
	option name 'eth1'
	option ipv6 '0'

config device
	option name 'WGINTERFACE'
	option ip6segmentrouting '0'

config device
	option name 'phy1-ap0'
	option ipv6 '0'

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

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/18000000.wifi'
	option channel '1'
	option band '2g'
	option htmode 'HE20'
	option disabled '1'
	option cell_density '0'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'EDIT'
	option encryption 'psk2+ccmp'
	option macaddr 'random'
	option key 'EDIT'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/18000000.wifi+1'
	option channel '36'
	option band '5g'
	option htmode 'HE80'
	option cell_density '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'EDIT'
	option encryption 'psk2+ccmp'
	option key 'EDIT'
	option macaddr 'random'

root@EDITNet:~# cat /etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option cachesize '1000'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option localservice '1'
	option ednspacket_max '1232'
	option filter_aaaa '1'
	list server '10.64.0.1'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'disabled'
	list dhcp_option 'EDIT'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'
	option dhcpv6 'disabled'


config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

root@EDITNet:~# cat /etc/config/firewall

config defaults
	option input 'DROP'
	option output 'ACCEPT'
	option forward 'DROP'
	option synflood_protect '1'
	option drop_invalid '1'

config zone
	option name 'wan'
	option input 'DROP'
	option output 'ACCEPT'
	option forward 'DROP'
	option masq '1'
	option mtu_fix '1'
	list network 'wan'

config zone
	option name 'WGZONE'
	option input 'DROP'
	option output 'ACCEPT'
	option forward 'DROP'
	option masq '1'
	option mtu_fix '1'
	list network 'WGINTERFACE'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'DROP'
	list network 'lan'

config rule
	option name 'Block Non-VPN Traffic'
	option src 'lan'
	option dest 'wan'
	option target 'DROP'

config rule
	option name 'Block Non-VPN Traffic2'
	option src 'wan'
	option dest 'lan'
	option target 'DROP'

config forwarding
	option src 'lan'
	option dest 'WGZONE'
6

I think that there is a good chance that the problem is related to your configuration, not a bug.

There’s a lot missing from the standard firewall, and you appear to have made a bunch of changes that are generally not necessary nor are they recommended.

I would recommend making a backup then resetting to defaults.

Once in the default state, install wireguard, and copy/paste the wg config back into your network config file (don’t include the device declaration with the wireguard interface — just the network interface and peer).

If the remote peer for WG is a commercial VPN service (i.e. treated as a wan and untrusted), create a new zone for it that is the same as the default wan zone (input and forward = REJECT; output = ACCEPT, masquerading enabled). Remove the lan > wan forwarding and create a lan > wg forward.

7

Also worth mentioning — just use plan psk2 for the encryption.

And do not add radio devices into the network config file

8

Sorry but your statement is utterly ridiculous. I followed a guide made by consumate industry professionals and you're telling me it's wrong and I should do it different way.

I modified some basic settings from within the luci interface to suit my needs and you're telling me that's causing the crash... sorry but thats absolute nonsense.

If you need more concrete evidence to prove your statement is trash - then also consider the fact that I'm currently connected to the router via ethernet and there are zero issues - 100% functionality - I can download anything and do anything and there is no crash - my setup is working perfectly.

The second I connect via wifi and try to download... Boom... goodbye router.

So please stop trying to defend openwrt and blame this on me when it absolutely is not. There's yet another horrendous bug in openwrt's firmware.

There was a nasty, crippling wifi bug in 23.05.4 and there's a nasty wifi bug in this release that cuases a crash and reboot.

Your suggestion that it's my setup is utter trash.

9

If you have a tty and cause the crash perhaps it will manifest to the screen. Some devices can keep the crash log across reboots, usually requires that you build it in and not sure about this particular device.

gotta ask why, perfectly legitimate, and if it is the cause, it is then a bug that needs to be resolved.

10

I am not going to argue with you. I will tell you, however, that the OpenWrt defaults are configured as they are for a reason. Generally speaking, the only reason to modify them is if you actually know why you are changing the configs and that you need to do so.

Pointing to an external website like that of a commercial VPN provider does not mean it is always correct or recommended for OpenWrt — they may have certain expertise, but I’m guessing they are not true experts in OpenWrt.

That said, you can backup and restore your configuration really easily. So trying the things I have recommended will at least get you closer to the default configuration which makes it easier for the dev team to then evaluate the specific possibilities of a bug — if this is reproducible in the default config, then it is indeed a bug that they can address. And if the problem still occurs, go back to what is at this moment the current configuration by restoring that backup, and you will be right back to where you were.

I’ll remind you that you are the one with the issue, and I am the one trying to help. If you don’t want to take my advice, fine. But fwiw, I’m extremely well versed in OpenWrt (and I have an MT3000, although unfortunately not with me at the moment).

7 Likes
11

Sure… but this will be yet another thing to help identify the specific root cause. Use psk2 alone and see if the problem occurs. If not, try psk2+ccmp and see if it manifests… the idea is to get back to what should work without issues and then you can change one thing at a time to find the root cause.

12

Why are you picking at miniscule facets of my setup such as wifi encryption choices when I come here detailing problems with a serious bug in openwrt's firmware?

13

See the comment I made above. psk2 should be really stable. If you want to use the psk2+ccmp option, let’s find out if that is the cause — helps the devs locate the potential culprits and root causes.

14

Great, if we knew that was the actual issue, cart horse kinda thing.

15

Instead of relying on debug logs which the OP may not be in a position to deliver (typically requires a serial console setup because the logs are stored in RAM and will be lost upon reboot), we can go at it by working with defaults and moving forward.

The OP could point logs to a local storage option, but internal flash memory is not recommended because of the wear it may cause (although for temporary use, that shouldn’t be an issue). USB storage would be better, though.

16

In the end, the only thing that matters, if this is truly a crash, is the stack trace of the kernel crash; i.e. you want it to happen.

17

I appreciate what you're saying, but you don't seem to be appreciating what 'm saying:

I am using the router right now... streaming TV through VLC, commenting here, I can download via usenet or bittorrent... everything is 100% perfect - but only via ethernet.

I spent time configuring my setup carefully, making minor changes and rebooting to check everything was ok, which it was - and still is...

... Apart from wifi - the second I connect via wifi and try to do anything - router crashes and reboots.

If I had any issue with my config I could not do everything like I'm doing now.

If you also consider there was another (totally different) wifi bug in the version prior to this (23.05.4) - how big of a leap does it take for you to concede that there's another bug in this release?

The proof is in the pudding - everything is working perfectly - apart from wifi - again - it's another bug in openwrt's firmare - there is clearly nothing wrong with my setup.

18

I have no issue with the suggestion that there could be a bug here… but I still recommend testing to see if the problem manifests in a near-default configuration. If not, we know it is config related, and we just need to know which bit of the config is responsible — if it turns out to be the psk2+ccmp or somehow the firewall, it is useful to know what appears to be the trigger. Then, it can be determined to be a bug by the dev team.

That said, we’ve had 23.05.5 out for about a week or so (sadly, I didn’t have time to update my MT3000, and I won’t be able to do so for another week+). If this specific issue is a true bug and as severe as you report, I would have assumed at least a few other reports might have been generated in the past several days… but it is still possible you are the first.

19

I can make it happen on command, that isn't an issue - it happens every single time I try to use wifi.

The problem is I can't get the log, maybe I can ssh in and grab some data up to the crash, I'll give it a try.

20

This is worth trying. But if it doesn’t reveal anything (the network connection may close before it can spit out useful info), would you be willing to try to repro with a default config?