Hello
I noticed a problem that I don’t know if it occurred in other beta versions before the release on 3/11.
I have two links, WAN1 and WAN2, whenever I leave them in balance mode I notice that Wireguard stops working. I return to failover mode and it operates normally again.
Has anyone else noticed this?
I use GL’s ddns to resolve my public IP, which is not fixed, and external access to Wireguard
Wireguard client?
When in load balance mode, the data can goes either connetion, causing your IP shift from one to another frequrenet. But it may not be a problem of vpn client. The vpn tunnel should be built and goes to one connection only.
In fact, this is a problem, as balancing should only be carried out with the output connections and not the input.
Another way to resolve this is to have an option to specify which wan interface ddns should use to define the public address that will be resolved.
OK so a little bit of an update, I was obviously using the WAN port for y internet connection, but I was using the 2.5ghz WAN/LAN port for my PC, and then LAN2 for a 2nd PC, I decided to move my PC to LAN3 instead and now I dont seem to have an issue on any of the firmwares, it doesnt take a genius to work out that the problem is looking more like unless you have anything other than a 2nd internet connection plugged into the WAN/LAN port and using it as WAN, then this is causing issues, ie using it as 2.5gb LAN.
Running the Stable 4.5.7 (19/Mar/2024)
About the information on Luci, it’s all buggy, I think your Wi-Fi region has been changed, but it will always say 00. If I’m not mistaken, this was passed on by one of the devs, but no solution was provided for this.
New “Stable” 4.5.7 as norm, release notes are an afterthought.
Releasing a stable version containing bugs in changing the country code and the unavailability of signal transmission check in Luci settings is a serious flaw, as it can mislead new customers.
It would be the same as buying a new car with the fuel gauge and the throttle panel broken.
@alex_zheng at least include a description in the changelog informing the bugs that are still present in the “stable” version to guide users!
Right, the transmission and country code bug should be fixed. I’m running the beta release on march 11th, 7 days up and thankfully no issues
Usually it’s not allowed to change the country anyway. Yep, by law.
@admon that is a crazy statement. The legal context varies tremendously by country. So unless you are a multi-national lawyer, you may want to dial that back. Further, if someone bought a router in one country but is using that router in another country, yes it is desired to be able to change the country so the power level and channels play nice with IoT devices.
It’s required by certification that you can’t change the country like you wish. So mostly it should be set to the country where you sold it.
That doesn’t make any sense. No regulatory agency goes to people’s homes to monitor which country code is configured on the router. They check, at most, the strength of the signal being transmitted by the router at that moment with their own equipment.
It would be a serious privacy violation if that happens!
It seems like most of of the 4.5.7 builds (including 2024-03-11) break many WIFI functions. As an example, using LUCI → STATUS → CHANNEL ANALYSIS does not work on any of the 4.5.7 builds I have tested. But if I go back to 4.5.6, release 1 with compile time 2024-01-19 03:08:54 (UTC+00:00), the Channel Analysis function works great as the base is 23.05 OpenWRT. So whatever is going on with the closed source WIFI drivers in 4.5.7 (21.02 OpenWRT base) seems to be breaking more than it is fixing. Yes, I understand that GL.iNet is not guaranteeing the LUCI functions, but these functions are useful and are part of the reason most of us bought a GL.iNet product to begin with.
It’s not about privacy or any other thing. It’s about the law. Law tells you that DFS must be used, f. e. - they don’t care about your feelings or what you want to do inside your home.
Usually devices are hardcoded to the country where they got sold. Portable (iPhone, f. e.) ones will use GPS for example to obey the law.
It’s a matter of privacy and following each country’s regulations. The MT6000 is sold as a global device, for use around the world. Therefore, it must allow the user to make the necessary changes to function correctly. Changing the country code on the router is one of the necessities to comply with local legislation!
Many other well-known brands like ZTE, Huawei, Tplink, Asus, etc. allow their users to change the country code.
@Thinner3614 agree with you. There is no regulatory truck driving around to arrest people. Yes, routers are by default set in NVRAM to parameters for the country (or region) where the device was sold. Mostly power level and frequencies (channels). But in a global world, people move around and bring their devices with them, so yes it is desired to be able to change the country if you are using the device somewhere else. @admon I get that you are trying to help, but you are digging a deeper hole. There are many WIFI certifications around the world in countries and regions. Unless you are an expert on every certification, suggest you dial back a little. I have looked at some of the certifications in my country for routers I own, and the testing only verifies frequencies and power levels in a test environment. And the testing is always contracted out to 3rd parties by manufacturers including GL.iNet. The regulatory body and manufacturer don’t even see the testing as important enough to do themselves.
I wonder if the 5 GHz (160 MHz) issue is resolved with the stable release of 4.5.7. If I remember correctly, it involved devices connecting and reconnecting multiple times resulting in websites not loading properly (or not at all).
I am not sure why it is called a stable release of 4.5.7 as many functions that are WIFI related are still broken.
Just WOW, 4.5.7 “Stable”??? Man I didn’t want to but I just can’t with GL anymore this is ridiculous…… ASUS Merlin here we go again……
