I have a GL-MT3000 configured in Access Point mode, firmware 4.7.4, no other custom configuration.
It works well most of the time, but the network interface will go down and then up again 4 seconds later as soon as I am in a Zoom call over WebRTC. This happens regardless of whether I use Wifi or Ethernet (the logs below have been captured with ethernet but wifi breaks likewise). It will happen multiple times during the call (as often as every 20 seconds).
I have tried reproducing the issue with iperf3 UDP load test between my laptop and the Beryl, but failed, so it's not a matter of network bandwidth. Likewise, speedtest.net reports good results. The problem is specifically with WebRTC.
Here is an example from logread showing the interface go down and up again:
Wed Apr 30 17:15:09 2025 kern.info kernel: [ 7728.883614] mtk_soc_eth 15100000.ethernet eth0: Link is Down
Wed Apr 30 17:15:09 2025 kern.info kernel: [ 7728.889399] br-lan: port 2(eth0) entered disabled state
Wed Apr 30 17:15:09 2025 daemon.notice netifd: Network device 'eth0' link is down
Wed Apr 30 17:15:13 2025 kern.info kernel: [ 7732.980443] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
Wed Apr 30 17:15:13 2025 kern.info kernel: [ 7732.989118] br-lan: port 2(eth0) entered blocking state
Wed Apr 30 17:15:13 2025 kern.info kernel: [ 7732.994368] br-lan: port 2(eth0) entered forwarding state
Wed Apr 30 17:15:13 2025 daemon.notice netifd: Network device 'eth0' link is up
Wed Apr 30 17:15:13 2025 daemon.notice netifd: lan (3842): udhcpc: performing DHCP renew
Wed Apr 30 17:15:13 2025 daemon.notice netifd: lan (3842): udhcpc: sending renew to 192.168.1.254
Wed Apr 30 17:15:13 2025 daemon.notice netifd: lan (3842): udhcpc: lease of 192.168.1.166 obtained, lease time 43200
Wed Apr 30 17:15:14 2025 daemon.notice netifd: lan (3842): udhcpc: performing DHCP renew
Wed Apr 30 17:15:14 2025 daemon.notice netifd: lan (3842): udhcpc: sending renew to 192.168.1.254
Wed Apr 30 17:15:14 2025 daemon.notice netifd: lan (3842): udhcpc: lease of 192.168.1.166 obtained, lease time 43200
I applied the workaround to swap LAN and WAN interface in Luci advanced interface (basically assigning WAN to eth1 instead of eth0, and swapping the ethernet cables) and I am not able to reproduce the issue anymore. Time will tell how reliable it is.
The root cause is unclear. Some of the bugs mention issues during speed negotiation with the upstream WAN router, because the default WAN port is expected to support up to 2.5G ethernet. The ones I've found are about the open-source drivers, and introduced in OpenWrt 23 so obviously don't apply to the Beryl firmware based on OpenWrt 21, but it seems clear that this Ethernet port is brittle.
I'd suggest adding an option in the "easy" interface to swap LAN and WAN, and documenting this as a known issue in the FAQ, so that the workaround is easier to apply without going through Luci.
I'm happy to run more tests or install alternative firmwares if it can help troubleshoot the root cause.
I notice that a number of them mention using a "Freebox" as upstream ISP router, which is also my case. So maybe there's something Free.fr does with their firmware that interacts badly with MT 7981 driver.
The GMAC corresponding to the WAN/LAN port of GL.iNet MT3000/MT2500 does not conform to the reference design. In order to ensure the normal function of HNAT acceleration, the latest source code of immortalwrt-mt798x has been corrected according to the mtk public version solution. Both of the above routers use 2.5G port as LAN port
The above may give a clue, the immortalwrt-mt798x build uses mtk HNAT drivers and they have had to reverse the WAN and LAN ports due to the 2.5G port breaking HNAT acceleration.
I use the device in bridge mode so there is no NAT (let alone HNAT) enabled. But there are quite a few bug reports about the PHY of the 2.5G WAN port, for various features, all of them leading to a reset of the interface. It looks like 2.5G isn't as battle tested as the rest of the code.
I experienced exactly this same issue when connecting my Beryl directly to a Mikrotik router using the 2.5G port. The Beryl is being used as a corporate hardware VPN device which I am unable to configure, so I've looked at solutions from the Mikrotik side.
As mentioned in post #1, when there was little to no activity, the link did not drop. A Teams call or downloading something causing a lot of activity caused the port to disconnect and immediately reconnect.
Two things worked for me:
Disabling auto negotiation and forcing the port to run at 100Mbit from the Mikrotik end (I am only connecting it to a 1G port anyway), or:
As mentioned above, plugging a dumb 1G switch in between also allowed the link to run at 1G and not drop
I believe the Beryl is running 4.5.2. I notice that in 4.6 the Mediatek drivers are now the closed source ones - I would be interested if someone is able to test this with a newer firmware.
Could you please share a PC remote desktop with us to remote check?
PC wired connection to MT3000
PC wireless connects another reliable WiFi, this for provide a stable remote connection
Install Zoom or Teams on PC, let's try to initiate a conference session
When the MT3000 reproduce the issue, the wired PC connection may disconnect with Internet. At this time, the remote desktop will use wireless, so as to continue to check it.
BTW, may I know what is the mirkotik router model?