luci VS gli-pub

https://github.com/openwrt/luci/tree/master/applications/luc...

From https://news.ycombinator.com/item?id=38138230 :

> LuCI is the OpenWRT web UI which is written in Lua; which is now implemented mostly as a JSON-RPC API instead of with server-side HTML templates for usability and performance on embedded devices. [...] Notes on how to write a LuCI app in Lua:

https://github.com/openwrt/luci/blob/master/applications/luc...

https://developer.hashicorp.com/vault/tutorials/secrets-mana... https://github.com/hashicorp/vault :

> Refer to Build Certificate Authority (CA) in Vault with an offline Root for an example of using a root CA external to Vault.

Yours will be easy. Just flash from the factory upgrade page. The error you are referring to was fixed in the current 22.03.0 version.

There is a fresh commit in, about three weeks old. See here: https://github.com/openwrt/luci/pull/5696 - so in a next release (minor, I guess) the feature will be included.

probably this repo https://github.com/gl-inet/gli-pub

The firmware is a huge mess and it's especially unfortunate that there seems to be some undocumented custom drivers or something else I haven't been able to identify yet which is missing from upstream OpenWRT, making it unusable for certain of their devices.

The gl.inet firwmare itself has a lot of missing updates and I am yet to successfully make custom builds of it (though in theory it should be possible through what's on their public Github repos, save for a handful of packages they provide as binary-only)

I should have taken better notes on building a firmware but I think what eventually allowed me to replicate and make custom build was to just build as if a normal openwrt dist from https://github.com/gl-inet/openwrt with a fork of https://github.com/gl-inet/gli-pub. Ended up ditching their custom hacky wireguard/tor functionality and mostly treating it as an openwrt dist.

The mwan3 stuff can be worth keeping and extending on using the uci module, though.

I will! Without the sketchy cloud stuff, the only thing I found so far was stuff like this, which I remove myself but is fully understandable - if you want to do connectivity-checking on devices used in Mainland China you don't have much options otherwise.

https://github.com/gl-inet/gli-pub/blob/326341dc5c14a256562e...

By extracting the firmware^1 one can see that GL.inet provides a cloud storage service. This is opt-in. It is not enabled by default. The cloud storage has a telemetry address listed in /etc/config/glbigdata. Perhaps one could probably use the service and change "telemetry.googcloud.xyz" to the loopback or delete it. No idea as I do not use cloud storage.

1. https://s3.us-east-2.amazonaws.com/download.gl-inet.com/firm...

With default configs IME one will see some constant traffic to 8.8.8.8. This is from OpenWRT mwan3's default configs. These defaults are left unchanged by GL.inet and probably other routers running OpenWRT. I have never seen anyone complain about this traffic. I doubt this is what is being referred to as "telemetry" in the above comment. Nevertheless, it is constant pinging to Google, OpenDNS or some other third party. In typical Linux fashion, mwan3, a daemon not every user is going to need, is enabled by default anyway.

https://github.com/gl-inet/gli-pub/raw/master/mwan3/files/et...