List of current feature requests 2023

It sounds like that’s easiest handled though adding additional lists through AdGuard Home should you have it. I think you’d still have to toggle those lists off/on when updating devices though. That might be a feature request to raise w/ them if they don’t already have it.

Another option is DeCloudUs. Set up a fully restricted list them, configure DOT/DOH within GL GUI → Network → DNS (requires SSH access to configure the conf). When you need to update client devices just change the GUI’s DNS to Cloudflare or Quad9, back to DeCloudUs when done.

1 Like

AdGuard query log is already HUGE (thanks to these telemetry datas) and I think Adguard is only filtering port 80 and 443,… :face_with_raised_eyebrow:

Repeating offenders (Attackers, these unknown telemetries, and known ADs showed blocked in Adguard), shouldn’t even reach Adguard after their IPs are in HOSTs list. For sake of simplifying Query Log,… this has to be done :face_vomiting:

DeCloudUs etc maybe nice but I prefer to keep things “local” as possible

I can respect that… but a local HOSTS file won’t help your devices (eg: mobile, tablet) when you’re elsewhere. On my GL device I do both: a local blocklist but DNS upstream is to DeCloudUs. Mobile to DeCloudUs.

Technically speaking it should be possible to extract those domains from the AdGuard lists & feed/convert them periodically into a local host/block list. How’s your knowledge of the Linux CLI?

Can we get tower locking on spitz ax?

Please follow this article : Lock Onto That Cell Tower - GL.iNet

[Feature Request] RTTY/SSH access within GL GUI

2 Likes

Re: Since firmware 4.6+, WireGuard & DDNS

The WireGuard watch dog script from WireGuard Extras hasn’t been tested?

# SPDX-License-Identifier: GPL-2.0
#
# Copyright (C) 2018 Aleksandr V. Piskunov <aleksandr.v.piskunov@gmail.com>.
# Copyright (C) 2015-2018 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
#
# This watchdog script tries to re-resolve hostnames for inactive WireGuard peers.
# Use it for peers with a frequently changing dynamic IP.
# persistent_keepalive must be set, recommended value is 25 seconds.
#
# Run this script from cron every minute:
# echo '* * * * * /usr/bin/wireguard_watchdog' >> /etc/crontabs/root
1 Like

This feature is under development and will be released in beta within this month if things go well.

2 Likes
2 Likes

Feature request - Band Masking:

  • allow band masking (OPEN or BLOCK) of WCDMA bands

This is a very small issue, but on my Spitz AX, the is no ability to either OPEN or BLOCK the WCDMA bands (only LTE, 5G NSA, and 5G SA bands are listed).

2 Likes

That strikes me as more of a bug than a feature request. One would expect the ability to lock down ea. individual of the set, no?

Feature request - Tailscale for Opal (GL-SFT1200)

  • It is capable of running WireGuard, therefore it is capable of running Tailscale. Sadly its architecture is ruining everything

Please don’t artificially limit devices.

1 Like

FYI: Tailscale is still in beta on the current stable 4.2.1-release4. “Upgrade to 4.x firmware for older products. (Beta versions of most models will be coming soon)” is stated to be released for v 4.6 so presumably that includes the Opal.

I tried to build it myself but failed pretty quickly, seems the Siflower/Sichang architecture is a bit different from regular MIPS so the binary won’t run. I really hope nobody pulls an “oh, this device is too old for us now, we don’t want to support it” kind of move. The beta is available for the Opal, just not tailscale, sadly.

Well good news, it seems! GL mentioned just 5 hours ago they’re building a 4.x for the Mango (GL-MT300N)… which was released, what, around 2017?:

… which is striking given what’s listed on

Great then! Still not the biggest fan of openwrt being seemingly stuck on 18.06 for my Opal, but I guess it’s fine as long as GL keeps updating it with patches and such

Then you’ll be happy to know GL f/w 4.2.1-release4, the current stable, is based on OpenWrt 21.02-SNAPSHOT. Their version 4.3 is mentioned to be based on owrt 22.0x.

They seem to be once release behind Upstream. I can live with that. YMMV.

Well, I’m currently on 4.3.2-beta1, it’s still 18.06. Seems like the version scheme doesn’t entirely correlate with OpenWRT releases haha

1 Like

Huh; well then… I guess that’s what I get for making an assumption of myself. I am corrected.

Hey, check this out fr GL re: Mango firmware: