ML-MT1300 (Beryl) Wifi stability is terrible with tons of 1-2s dropouts

Technical Support for Routers
2

I totally agree.
While browsing this forum I figured I could try the modified firmware with updated 5.1.0 wifi drivers found here: GL.iNet download site (gl-inet.com).
This partially fixed the issue, with the 2.4ghz looking pretty stable. At least wifi is useable in 2.4ghz. However the 5ghz is still randomly dropping every 2-5 minutes, and I unlocked the region and tried all possible bandwidths, channels, etc. Using a totally free channel doesn’t help whatsoever.
It seems that selecting the “Low” Tx power makes it somewhat more stable than the others, but 5ghz will still drop at some point and after a few times it will give up (won’t accept new connections until a reboot), while 2.4ghz will still be up and running.

So my advice is to upgrade to the above mentioned firmware and stick to 2.4ghz until they release a stable firmware with good wifi drivers.

3

Just to confirm, this is in router mode, not AP mode, right?

4

Yes, router mode with Ethernet WAN and Wireguard VPN Client mode.

I did a clean install of the “oops track” FW and I think the problem is fixed. Now Wifi doesn’t drop every 45 seconds and it stayed up overnight.

I didn’t touch any of the wifi settings, left everything Auto and Max Tx, as I suspect that changing channels manually can break wifi, even with reboot.

5

I left the pings going overnight (8 hours), on freshly factory reset Beryl with release 3.203 and there was only 1 dropout that lasted for 2 seconds, so I guess thats an improvement.

The ping variance is still not good, with pings going up to 100ms-200ms while pinging the router LAN IP from a meter away with nothing else going on. There seems to be a pattern though, router will go from 2-3ms stable pings to bursts of increasing latency pings to revert back to normal. Home router pings are solid 2-3ms for hours so it’s not a 5GHz interference issue, I’m a meter away anyway. Like if something is hosing up WiFi packet processing for short periods of time (bad drivers?) Hopefully not a problem with HW

@alzhao yes, this is in router mode.

I’ll try later the testing FWs mentioned by @sundaydriv3r

Example here:
5Ghz band, router mode, completely idle router (no connections other than laptop), factory reset 3.203 release. Should be easy to replicate.

…
64 bytes from 192.168.8.1: icmp_seq=46274 ttl=64 time=2.051 ms
64 bytes from 192.168.8.1: icmp_seq=46275 ttl=64 time=2.645 ms
64 bytes from 192.168.8.1: icmp_seq=46276 ttl=64 time=2.491 ms
64 bytes from 192.168.8.1: icmp_seq=46277 ttl=64 time=2.489 ms
64 bytes from 192.168.8.1: icmp_seq=46278 ttl=64 time=2.508 ms
64 bytes from 192.168.8.1: icmp_seq=46279 ttl=64 time=2.388 ms
64 bytes from 192.168.8.1: icmp_seq=46280 ttl=64 time=3.484 ms
64 bytes from 192.168.8.1: icmp_seq=46281 ttl=64 time=21.905 ms
64 bytes from 192.168.8.1: icmp_seq=46282 ttl=64 time=41.471 ms
64 bytes from 192.168.8.1: icmp_seq=46283 ttl=64 time=60.549 ms
64 bytes from 192.168.8.1: icmp_seq=46284 ttl=64 time=2.524 ms
64 bytes from 192.168.8.1: icmp_seq=46285 ttl=64 time=101.888 ms
64 bytes from 192.168.8.1: icmp_seq=46286 ttl=64 time=19.145 ms
64 bytes from 192.168.8.1: icmp_seq=46287 ttl=64 time=41.967 ms
64 bytes from 192.168.8.1: icmp_seq=46288 ttl=64 time=2.089 ms
64 bytes from 192.168.8.1: icmp_seq=46289 ttl=64 time=2.729 ms
64 bytes from 192.168.8.1: icmp_seq=46290 ttl=64 time=2.749 ms
64 bytes from 192.168.8.1: icmp_seq=46291 ttl=64 time=2.574 ms
64 bytes from 192.168.8.1: icmp_seq=46292 ttl=64 time=3.460 ms
64 bytes from 192.168.8.1: icmp_seq=46293 ttl=64 time=2.642 ms
64 bytes from 192.168.8.1: icmp_seq=46294 ttl=64 time=2.056 ms
64 bytes from 192.168.8.1: icmp_seq=46295 ttl=64 time=1.953 ms
…

6

I get the same issue over wifi.
I’ve just updated to the latest beta firmware (released 1 march 2022) and I get exactly the same issues.
No difference for 2.4 or 5hz.
Any other suggestions? It makes video calls awful.

7

Are you wired on the WAN port by any chance? I get the 45 second dropout for 2-3 seconds if I connect to the internet through the WAN ethernet port of the MT1300. If its wireless to wireless seems to disappear.

8

The router is connected to my main internet connection via the wired WAN port then my devices (e.g. laptop, ipad) are connected via the wifi.

I only experience this dropout on the devices I have connected via wifi.

I have two devices on the wired LAN and they don’t appear to have any dropouts.

9

You are confirming the setup that is producing the 45 second dropout for me too: Main internet connection is wired to WAN. Dropout happens on WIFI side.

However, if I configure router as repeater (main internet is wireless Wifi) I don’t see the dropout. If you could replicate this behavior (I understand is not a long term solution and is slower for now) we can have gl-inet reproduce it and hopefully fix.

10

Thanks - I’ll give that a try later and report back

11

I get the same result.

If i set the router up to connect as a wifi repeater and then I connect via wifi from my devices then there is no dropouts in connection! Only when using wired connection from router to get internet access!

12

Can you do a top level post about this with all the details so it gets attention? FW used, specific step to reproduce, … I’ll add confirmation. They’ll likely look into it.

13

@boggler and @glinetlvr

Today I tested 3.212 snapshot. I connected cable as WAN and also tested repeater. Both 2.4G and 5G wifi performs normal without timeout.

Pls test 3.211 and later. Do not test 3.203 and older because wifi driver has been updated.

Some ping lag on wifi is normal.

Timeout is not. So I assume this is the problem we are trying to solve. Appreciate it if you can clarify the issues so that we narrow down to the root causes.

14

Thanks will test on 3.211 stable later from here GL.iNet download center

Yes it is timeout (not lag) that is the issue.

One setting I have in place is mac address cloning on the router that may be different than a standard install. But apart from that the settings are pretty standard.

15

Just be careful about mac clone because sometime people mess up and cause the network crash.

So if you can test with or without mac clone that will help.

16

Tested on 3.211 stable and all worked fine - no dropouts!

This was with cable in WAN and mac address clone.

So problem solved. But maybe an issue in the beta.

17

FWIW, using my Beryl as Router, with my hotspot device connected via USB, I get disconnects every minute on all my connected devices. Setting the 2.4GHz to only 20MHz wide channels seems to have stopped it- for now- but I’ve tried a few things and sometimes it stops when I reboot, sometimes it doesn’t.

Running the 3.211 firmware. I even put a USB-C power meter on it thinking it might have been power related, it never draws more than ~3W (4.95v/.8A) and this is on the PS you guys supply, but a couple of PD power supplies I’ve got exhibit the same behavior.

Here’s some lines from my laptop’s syslog showing the behavior. It’ll do this over and over:

Apr 17 01:19:25 xps-7390 systemd-networkd[462]: wlan0: Lost carrier
Apr 17 01:19:25 xps-7390 vmnetBridge: Removing interface wlan0 index:3
Apr 17 01:19:25 xps-7390 kernel: [12851.826441][  T797] wlan0: authenticate with 94:83:c4:15:03:13
Apr 17 01:19:25 xps-7390 kernel: [12851.826462][  T797] wlan0: Invalid HE elem, Disable HE
Apr 17 01:19:25 xps-7390 kernel: [12851.829479][  T797] wlan0: send auth to 94:83:c4:15:03:13 (try 1/3)
Apr 17 01:19:25 xps-7390 kernel: [12851.859446][ T3437] userif-3: sent link down event.
Apr 17 01:19:25 xps-7390 kernel: [12851.859449][ T3437] userif-3: sent link up event.
Apr 17 01:19:25 xps-7390 kernel: [12851.964341][T14258] wlan0: send auth to 94:83:c4:15:03:13 (try 2/3)
Apr 17 01:19:25 xps-7390 kernel: [12852.066614][T14258] wlan0: send auth to 94:83:c4:15:03:13 (try 3/3)
Apr 17 01:19:25 xps-7390 kernel: [12852.167298][T14258] wlan0: authentication with 94:83:c4:15:03:13 timed out
Apr 17 01:19:27 xps-7390 kernel: [12854.028267][  T797] wlan0: authenticate with 94:83:c4:15:03:13
Apr 17 01:19:27 xps-7390 kernel: [12854.028289][  T797] wlan0: Invalid HE elem, Disable HE
Apr 17 01:19:27 xps-7390 kernel: [12854.031210][  T797] wlan0: send auth to 94:83:c4:15:03:13 (try 1/3)
Apr 17 01:19:27 xps-7390 kernel: [12854.170631][T13088] wlan0: send auth to 94:83:c4:15:03:13 (try 2/3)
Apr 17 01:19:27 xps-7390 kernel: [12854.172318][T13088] wlan0: authenticated
Apr 17 01:19:27 xps-7390 kernel: [12854.172600][T13088] wlan0: associate with 94:83:c4:15:03:13 (try 1/3)
Apr 17 01:19:27 xps-7390 kernel: [12854.176091][T13088] wlan0: RX AssocResp from 94:83:c4:15:03:13 (capab=0x131 status=0 aid=1)
Apr 17 01:19:27 xps-7390 kernel: [12854.178562][T13088] wlan0: associated
Apr 17 01:19:27 xps-7390 vmnet-natd: RTM_NEWLINK: name:wlan0 index:3 flags:0x00011003
Apr 17 01:19:27 xps-7390 vmnetBridge: RTM_NEWLINK: name:wlan0 index:3 flags:0x00011003
Apr 17 01:19:27 xps-7390 kernel: [12854.278092][T13088] wlan0: Limiting TX power to 20 (20 - 0) dBm as advertised by 94:83:c4:15:03:13
Apr 17 01:19:28 xps-7390 vmnetBridge: RTM_NEWLINK: name:wlan0 index:3 flags:0x00011043
Apr 17 01:19:28 xps-7390 vmnetBridge: Adding interface wlan0 index:3
Apr 17 01:19:28 xps-7390 systemd-networkd[462]: wlan0: Gained carrier
Apr 17 01:19:28 xps-7390 vmnet-natd: RTM_NEWLINK: name:wlan0 index:3 flags:0x00011043
Apr 17 01:19:28 xps-7390 systemd-networkd[462]: wlan0: Connected WiFi access point: KennyBeryl (94:83:c4:15:03:13)
Apr 17 01:19:28 xps-7390 kernel: [12854.522705][ T3437] userif-3: sent link down event.
Apr 17 01:19:28 xps-7390 kernel: [12854.522712][ T3437] userif-3: sent link up event.
Apr 17 01:20:09 xps-7390 vmnetBridge: RTM_NEWLINK: name:wlan0 index:3 flags:0x00001003
Apr 17 01:20:09 xps-7390 vmnetBridge: Removing interface wlan0 index:3
Apr 17 01:20:09 xps-7390 systemd-networkd[462]: wlan0: Lost carrier
18

Does the 5GHz wifi band also have disconnects?

Can you post the System Log (logread) on the router?

I do not work for and I am not directly associated with GL.iNet

19

Well, seeing advice I’d seen about this from earlier, I totally wiped my Beryl and redid my setup, and so far, so good- no more WiFi flapping. I’ll be using it non-stop for a couple of weeks, so if it happens again I’ll report back.

1 Like
20

Im curious as to how many devices you all have connected? Ive found the beryl wifi to be unreliable in my use case, with more than 20 devices all in my overlanding rig. I ended up using a unifi ap because between the beryl and slate, after a few days, they stop working. using later software almost like I am overloading them. Once I started using a separate AP, issues went away… not recommending gl.inet anymore, the thought of a raspberry pi router sounds more appealing.

I mean… still releasing firmware on openwrt 19.07.8… why? yeah, I’m disappointed!

21

For me, usually no more than 3-6, and split between both bands. And FWIW, since wiping and re-config, my Beryl has been rock-solid.