Had anybody issue with a new stable firmware4.9.0 after upgrading it got so slow that router was almost unusable? I mean really really slow, almost not working? Even SSH took 15secs to get connected, admin panel impossible?
Hi,
That sounds a bit unusual, as we have not seen similar reports before.
Could you please try resetting the device to factory settings and see whether the issue still occurs afterward?
Hi will, so I’ve been able to downgrade to 4.8.4 (slow process and had couple timeout errors) with a firmware from GL.inet webpage. Router got into normal operation HOWEVER I’ve noticed that AdGuard Home been crashed, couldn’t even open AdGuard setting in 192.168.8.1:3000. So I’ve uploaded my last backup file, after that all was okay.
I’ve tried upgrade to 4.9.0 again, but now with ‘DO NOT KEEP SETTINGS’ (fresh installation), and I can confirm everyrhing is running fine as supposed to.
So the issue seems to have been caused by upgrading from v4.8.4 to v4.9.0 while keeping the existing configuration?
If you still have the previously exported configuration file on v4.8.4 and are willing to continue troubleshooting, you can send it to us via private message.
We can then check it locally to see whether there was any configuration conflict causing the issue.
In any case, we’re glad to hear that everything is now working properly.
I had a similar issue (maybe less critical, but still annoying …) After upgrading from v4.8.4 to v4.9 while keeping the existing configuration, the previous speed decreased by approx 60% … I have just reloaded the v4.8.4 and all the performances have been restored. Upgrading without keeping the existing configuration would be out of discussion because I have two 2.5 Gbps FTTH services with iPv6 not easy configuration and several static routes that I have optimized after several optimization cycles that would be extremely difficult to be restored from scratch … Is there any way to upgrade to v4.9 while keeping the existing configuration and avoiding worst performances with respect to v4.8.4? Thanks
Hi,
Could you please check whether any WireGuard / OpenVPN / ZeroTier-related features are currently enabled?
If so, please try disabling them and see whether that helps.
Alternatively, please follow the guide below to export a backup file and send it to us via private message. We will try checking it locally to determine what may be causing the issue.
Hi,
only WireGuard was enabled. I disabled it and and retried to upgrade the BE9300 to v4.9, but the issue was experienced again: Speedtest with v4.8.4 is stable at 2353 Mbps (Download) / 686 Mbps (Upload), but with v4.9 it decreases at approx 838 Mbps (Download) / 687 Mbps (Upload). By restoring it to v4.8.4 and also re-enabling WireGuard, the better performances are reestablished.
I have sent the configuration with a private message.
Hi,
Thank you for providing the configuration file.
After reviewing your setup, we confirmed that simply disabling the WireGuard Server does not completely resolve the issue.
To further troubleshoot, please disable the WireGuard Server and then SSH into the router to execute the following commands:
[ -e /sys/kernel/debug/ecm/gl_front_end_ipv4_stop ] && echo 0 > /sys/kernel/debug/ecm/gl_front_end_ipv4_stop
cat /sys/kernel/debug/ecm/gl_front_end_ipv4_stop
Please let us know what value is returned by the cat command and whether this step resolves the issue on your end.
We will also try to address this problem in a future firmware release.
Sorry for answering so late (for a strange reason I did not receive any notification of your message).
Unfortunately disabling the WireGuard Server would be not applicable in my case because it is actually the main feature that push me to use the Router, and it is not clear to me if after executing the commands that you have indicated I’ll be able to re-enable the WireGuard Server again.
My understanding is that a next release would be required to definitely fix the issue. Is it correct? Do you have any schedule for such next release?
Thanks
Thank you for the update.
Yes, we are already working on a fix for this issue internally and plan to include it in a future release.
However, there is no ETA available at the moment.