I already sent a message to the gl.inet support about those issues, but I still thought it could be helpful to post this information here in case someone else faces the same problems that I do …
5GHz channels: The selection of a region/country and thereby the selection of appropriate (and law conforming) WiFi settings is not possible using the standard GUI of FW 3.201. Applying the correct settings is not even possible by using “luci”, because NO “advanced settings” are available in the luci GUI for any adapter (see other threads about missing “advanced settings” tab).
This is a serious deficit not only because you are limited in the number of channels for the WiFi of the device itself (if you “only” wanted to use it as AP for wired WAN) – even worse: you cannot connect to 5 GHz WiFis for uplink (!) (WISP=WiFi as WAN) that are currently using channels that are not available/cannot be seen due to an inadequate country-specific channel configuration (for example: if the 5GHz WLAN you want to connect to is using channel 112 (which is allowed in Germany) you do not even see this WLAN in the dropdown list of the scan result with the default/factory country setting “CN”). IMHO especially a router designed as a travel routermust support all possible/allowed channels for Uplink, because for obvious reasons you usually have no possibility to take influence on the channels used in the WLANs of your hosts when you travel…
I was able to get around this by modifying “/etc/config/wireless”: a) change “country” to “DE” for both adapters, b) change “region” to “1”, c) change “aregion” to “7”, but still: this has to be configurable by GUI!
DFS: Which leads to DFS support: if you enable all channels that are allowed in your country/region (in my case: Germany) you have to rely on DFS working properly. I found a workaround by adding “iw reg set DE” to “/etc/rc.local” (by using luci > System > Startup > Local Startup) or WinSCP, but: I am not sure, whether it really works (the syslog / kernellog do not provide much information).
I really hope, these issues will be fixed in upcoming FW versions.
I totally agree. I find it unbelievable that the basic configuration does not take this into account. Thank you very much for your help. For Spain I have used the same parameters, except for the country which I have set to “ES”, although the effect will be the same as for Germany.
Now I can configure the 2.4 and 5 GHz channels that I couldn’t see before.
I think I’ve seen that both the Beryl and Mango use proprietary MT drivers, while Openwrt uses the opensource drivers. The proprietary drivers aren’t compatible with luci.
Is the plain openwrt build on the Gl-Inet website for Beryl and Mango using the proprietary drivers, or the opensource drivers? Has anyone tried the opensource drivers recently? I know they are being actively developed.
Dear alzhao, with all due respect: I understand the difficulties in developing software using non-open-source drivers. But: getting the country-settings work correctly (i.e. starting with making it possible to select the correct country / region via GUI) along with getting DFS work correctly is not an issue of “low level hacks” - it is a basic requirement for operating your routers in accordance with regulatory requirements! And, as you might see from the rising number of posts, the issue affects the basic operation of the router because users find themselves being unable to connect to certain 5 GHz networks!
Over the last evenings I ran several tries with the latest OpenWrt RC (21.02.0-rc1) and several snapshot builds. The positive experience was that the newer drivers seem to provide better hardware support (Luci supports Advanced Settings and you can select a country). Regrettably until now I only succeeded to join to an uplink WLAN (by the way: even to a EAP2-Enterprise network!), but I have not succeeded in activating the downlink radios (i.e. I could not connect to the Beryl with other devices, be it with 2,4 or 5 GHz). I spent several hours trying to get a little bit more information out of the few documentation available on the web and to find ways to communicate with the drivers, but i must confess: I touched the limits of my technical knowledge and did not get any further yet. And one should mention that with using OpenWrt you not only loose the nice GLinet-GUI, you also loose the preconfigured VLAN architecture including the seperated guest wlans, the virtual switch etc. Of course it is possible to configure that yourselves, but is takes some effort. Long story short: GL.inet should get behind a working firmware quickly, so do I think.
I wonder if you might try the current 19.07.7 so it is more apples-to-apples. The MT76 “newer drivers” --which are the Linux drivers as well as the Openwrt drivers–I think should be the same, but it might be a problem with 21.02.
I think Luci supports only the opensource drivers, which is why you get Advanced Settings. And, as far as I can tell, the MT76 drivers only purport to support the Mango (7628AN) and not the Beryl (7621).
No, I have not tried latest stable release 19.07.7 yet. But I agree: the problems with Luci, 5GHz-Channels, country selection and DFS seem to be correlated with open vs. closed source drivers for the Mediatek chipsets. As I occasionally found in another thread (2021, gl-inet Firmware 3.2, shorttest of snapshot version - #29 by luochongjun), luochongjun is already aware of the problems. The core question is: will the gl.inet-developers team be able to fix the issues at least with FW 4.x or will they not - assuming that MediaTek will not grant open access to their code …
#elorimer
Today is the last day I can return the Beryl to Amazon, so decided to give OpenWrt 19.07.7 a try. Regrettably, there ist no build for that [OpenWrt 19.07.7 Targets] (Index of /releases/19.07.7/targets/ramips/mt7621/). So, given the fact I have not found any relyable information about when the bugs/issues discussed will be tackled by the GL.inet developers (maybe by FW version 4.x - whenever this will be released) and based on the assumption that the underlying problem of open vs. closed source driver will not simply vanish I choose the safe option of returning the device. I will give the GL-AR750S-Ext (slate) a try, instead.
By the way - if I was GL.inet and/or in the team of developers I would try to provide more structured information about confirmed/accepted bugs, feature requests and the state of FW development in general to my customers. If I, for example, would have had more reliable information about the priority with which the issues of my concern were being addressed or an estimation for the time they could be resolved, I would have been more likely to keep the product and to wait for the bug fixes.