GL-MT3000 Beryl AX drops connection every couple of hours

Technical Support for Routers
1

Hi

I recently bought Beryl and flashed 4.7.0-op24 so I can connect to University WiFi.as my Internet source. I can connect however every 5-10 hours Internet stops working and if I login to the router click on Internet then Modify and Apply it reconnects and Internet works again.
I have other devices directly connected to the same University WiFi and they never drop the connection.
When I ask GL.inet support they say this router doesn't work with EAP however as I said I can connect with above firmware only problem is that connection keeps dropping.
Should I return the router and buy another or is there some fix? What router you suggest for stable and working EAP connection?

Thanks

2

Hello,

the Beryl AX with the 4.7.0-op24 is supported to repeat the public wifi with the EAP.

Please PM me the issue syslog including this process about the repeater disconnected, and you manually re-connect it.

4

University wifi, I expect multiple AP's with the same SSID.
EAP is not the problem.
GL.inet needless swapping AP's if it has multiple posibilities was a known problem.
Using BSSID lock helps a lot against this.
(Multi WAN action on internet check should be set as (s)low as possible, or that AP-swap will initiate session drops (firewall reload) when interface goes down and up in that swap)

5

hi bruce
Thank you very much for the response. I am on a trip, as soon as I am back I will get the logs and post them here.

6

Thanks bpwl1, I will try the lock and let you know if it worked.

7

I just sent you the logs right after I reconnected through UI.

1 Like
8

Hi bpwl1, unfortunately using BSSID lock didn't help.

9

One thing I want to add that when I reconnect to Eduroam with 2.4ghz if my other devices connect to my 5Ghz WiFi, they don't work although all devices show connected WiFi (like there is internet, however when I try to open web page for example it doesn't work). This stays like this until I reboot the modem.
I have basically until Tuesday to return the modem, so if I don't resolve it by then, I will have to return it as there seem to be too many issues with it for my use case. I would really like to solve this and get stable connection as I like the modem and it's features, but it doesn't look like it is going to happen in the next 2 days.
Also I don't understand why would modem want to automatically scan and pick different SSIDs upstream internet WiFi in repeater mode by default (unless set it to fixed BSSID). That's almost never desired behavior. Unfortunately fixing it didn't help as well.

10

Roaming wifi connection is there to find the "better" connection, avoiding what is called "sticky clients" . "Sticky clients" connect and stay connected to that first connected AP until the wifi connection is disconnected. "Sticky clients" remain connected even is the signal is very weak, and the transmission quality is low. Wifi adjusts by lowering the number of streams and by lowering the MCS encoding, resulting in a very slow connection (interface rate from 866Mbps in steps down to 6Mbps) with many retransmits, consuming a lot of "air time" on that channel, slowing down everyone on that channel. (Wifi can only have one transmitter in a channel at a time, therefor air-time is a very limiting resource).(Wifi does not drop packets, but retransmits until disconnected)

A client station will roam faster if the link is bad, and should stay connected if the link is good. Unfortunatly estimating good/bad is problematic with wifi. Signal strength is a poor indicator for this.

Unfortunatly my experience with GL.inet (SFT1200 version 4.3.x) is that the GL.inet roamed for no apparent reason. One of the reasons found is that GL.inet then mishandled MPDU aggregated transmissions with more than 31 MPDU's aggregated, giving failed transmissions, due to its own processing with good wifi, now signaled as bad wifi.

Roaming is within the same SSID, but GL.inet (like most smartphones) will also try whatever other known SSID. So if there is more than one known SSID in your Beryl, even with BSSID lock it will roam to that other SSID. Only one known SSID and BSSID lock are needed to stabilise.

Yet another GL.inet choice is using Multiwan (mwan3) checks, what will trigger switching to another or switching off/on connections, based on those checks. The ifdown/ifup actions in router "Network Mode" include the tear down and reload of the firewall with all current IP sessions (Checks may fail even due to a busy internet, independent from the wifi connection quality). Stopping Multiwan checks is here just another mitigating action.

GL.inet has many problems with stable TXpower control, at least on my SFT1200 this is dramatic. Setting TXpower to LOW gives stronger signal than HIGH or MAX.

Debugging wifi connections is like sitting in front of 7 switches connected in series. Not knowing what and how many switches are in the wrong position, finding the right setting takes 128 combinations. And if the lamp is not very stable, one might miss that one single correct combination when selected.

1 Like
12

Thank you for the explanation, I really appreciate it. Interesting is that all my other devices including phone, tablet and laptop when connected to the same Eduroam WiFi do not have these issues. I mean they probably do the same thing but they never disconnect. And I guess that the router should not drop connection altogether in any case. It's obviously software doing something wrong as if I just reconnect it works, which means that it could do it as well automatically if this process was working correctly like in other devices.
And then there is another issue where after I reconnect manually to the upstream other devices connected to the router show as connected but internet is not working until I reboot the router.
I really like gl.inet for all the features it has power it gives to the user but I think that basic stuff like this should work out of the box in each firmware and no firmware should be released before it is tested. I mean with fresh latest firmware I am just trying to use it as repeater, there is no simpler use case for this kind of router (otherwise for simpler stuff I could use any router) and it doesn't work out of the box.
I am software engineer and don't mind changing some configs even ssh into the router and do some stuff but I really don't have time to read 16 hours about network protocols/algorithms just to setup repeater and share a WiFi with other devices.
It's good to have powerful routers which are configurable but there is a limit in how much time people not into networking can spend to get their network to work.
I sent my log to @bruce and I hope he will figure out the issue before I return the router.
I thought I will setup this part in 10 minutes and then spend some more time setting up VPN/obfuscator to avoid Eduroam blocking of VPN, and thought I should be able to setup everything in few hours. Silly me :slight_smile: .
In any case thanks for the help and I think the gl.inet community is great and hope will be able to get it to work as it has much more possibilities than regular routers I used before.

13

Let's hope they make it work. The extra features are sometimes nice, but sometimes just bad (see my SFT1200 comments: "The Good, The Bad and The Ugly")

Actually the "extender" network mode is a complex case, because the IEEE802.11 standard does not handle this possibility. 802.11 wifi uses only 3 of the 4 needed MAC addresses. Good for "AP tot station" wifi, where "station" is a single device, because the 'destination' MAC is missing in the standard, unless you use WDS or bridge Wifi, but that is implemented differently per manufacturer or product generation, and seldom compatible.

This is here not causing the GL.inet wifi disconnect problem. Wait untill you get DHCP lease problems, or failing reverse connection (that is to devices behind the extender) those are extender related problems.

Don't know if GL.inet is checking the interworking profile information, (Hotspot2.0) , quite common for Eduroam networks. Configuring Hotspot 2.0 / Passpoint 2.0 on OpenWRT

15

If this issue occurs again, please do not re-connect the repeater, and export the syslog first.
And please help to execute in the SSH to see if the repeater interface has obtained the IP address and whether it can ping the gateway:

ifconfig
ip route
ping <repeater (apcli0 or apclix0) gateway IP>

Example:

image
image790×160 6.26 KB

The repeater gateway IP is 192.168.18.1

Addiction:
If the condition is satisfied, could you please share the router with us via GoodCloud?
Probably it required to connect a wired WAN or Tethering to provide the first WAN (for the stable Internet connection), and the Repeater (EAP) as the second WAN (for the debug).

16

Hi,

Please check this output:

root@GL-MT3000:~# ip r
default via 149.157.144.1 dev sta0 proto static src 149.157.150.35 metric 20
149.157.144.0/21 dev sta0 proto static scope link metric 20
192.168.8.0/24 dev br-lan proto kernel scope link src 192.168.8.1

As for sharing the router via GoodCloud, I can do it but only way to add additional Internet connection is by sharing my phone network so not sure how we can sync time when I am home.
The issue happened today also but I later on saw the message. When it happens again I will export the log first and send you.

Thanks

17

Hi @bruce, are there any updates on this. My router is unusable as it is now. Is there at least some temporary fix which for example reboots router if connection is not detected automatically.
Router simply doesn't reconnect to the wifi after it looses connection and stays like that until I reboot it or login to interface click modify->apply. Why can't it automatically do that. I would expect that if it looses connection it should try to reconnect automatically.
All other devices work without issues with the same Wifi.

Thanks

1 Like
18

Hundreds of Gl-Inet engineers are working around the clock to fix bugs and optimise firmwares. I’m sure this will be fixed soon™

19

Hello,

We have built a similar environment and tried to reproduce locally, but unfortunately we were unable to reproduce the issue.

Since we suspect it is an issue with wireless OTA interaction, we think to reproduce it, so we can catch the wireless OTA packet and check it.

In addition, we have checked the configuration information related to your router's relay several times, and found no difference with other "eduroam" users.

We are still working to reproduce the issue.

  1. If possible, try to reset the firmware and configure it again.
  2. If 1 no luck, please try adding this on the crontab (Luci > System > Scheduled Tasks) as the workaround, it will make the repeater interface restart every 4 hours.
    0 */4 * * * /etc/init.d/repeater restart

image
image1056×685 15.2 KB

20

Thank you for the tip, I added it to the cron and let's see if it will temporary solve the issue until the real fix is there.

21

Hello,

We checked it through GoodCloud that after setting the timing to restart the repeater process, there was 1 time a connection exception.

Comparing other eduroam users and environments we have been exposed to, there is no difference in your eduroam.
We are in doubt and guessing that there may be any restrictions on this one eduroam WiFi AP device which currently connected from the MT3000.

If possible, please help us to do these 3 tests:

  1. Directly connect to eduroam on a laptop, continuously check ping to see if there are packages lost during the period.
    Windows CMD: ping www.google.com -t, Mac Terminal: ping www.google.com

  2. On the same campus, move MT3000 to another building (not in the current dormitory or teach building).

  3. Enable MAC clone or Camouflage on MT3000, to simulate it like a laptop or pad.

22

Hi,

  1. I am already 100% sure that no packages are lost during the period when router disconnects. I already tested that several times.
  2. Unfortunately I am not able to do it or properly test as this is happening after some hours and I don't know when it will happen. So even if I bring router to another part of the campus I cannot wait for hours there and also have no means to actually test it as all my PCs are at my current location.
  3. This is already enabled for at least 2 weeks.

"We are in doubt and guessing that there may be any restrictions on this one eduroam WiFi AP device which currently connected from the MT3000."
I don't know if there are some restrictions for routers, but definitely laptops/phones/tablets/PCs work flawlessly and never disconnect.

Is there is some better "hack" to solve it even if you cannot figure out the root cause it would be helpful. For example only restart the repeater if pinging some public service stops instead of restarting it every 4 hours?

I think it would be useful for Gl.iNET to resolve this issue as I am not using anything special, just a normal University eduroam WiFi. And this is not some small unknown university, thousands of people are using this WiFi without issues.

Thanks

23

AFAIK ...

Wifi (802.11) transmission never drops or loses packets, it retries untill acked, If it cannot succesfully send a packet (after retries and after lowering MCS level, and reducing bandwidth and # of streams, and after an extra retry period with continous retries) it disconnects.

Only some wifi drivers allow to set a "frame lifetime" in their advanced settings to remove a lingering packet in the TX queue.