I'm curious as to why y'all use an ancient version of openWRT for the basis on this router?
OpenWRT 21.02 went out of support years ago - and trying to get help from the openwrt developers has been an exercise in pure frustration (they tell me the hardware wasn't even fully supported until 23.05.3).
So they're making it sound like y'all have hacked away at an ancient version of their firmware to make it work with this hardware, rather than using something that they are willing to help with.
Doing so limits the ability to get support when nobody here can help with an issue.
Seems like being closer to stock (with your simplified UI - which I actually really like - being an add-on that doesn't change how the firmware fundamentally is built or works) would be beneficial for y'all so your customers can leverage openWRT's support as well as yours.
I wish they would just drop mtk sdk and fork out a clean 24 full release openwrt
Currently the op24 version is not a real 24 release, but forked a little earlier from the main branch (snapshot branch when v24 was still developed) which is highly experimental.
Currently I run on the master branch (v25) with my own compiled OpenWrt without any gl ui, and it works perfect for me.
I see lately more issues arise with their mtk sdk because some packages do not work or compile correctly, or they get removed.
And as far as I know APK is not yet in 24 as package manager.
That's good to know, thanks! Yeah, I'm trying to solve a problem on my Flint 2 with it not letting a VPN connected device (wireguard) connect to an internal web service on the WAN interface's IP address - like I get with NAT loopback from the LAN interface - it keeps trying to connect to the router's https port.
I asked over in the openWRT forums, and got a lot of pushback because it's "not official openWRT" and the current openWRT releases use nftables rather than iptables (which is what the glinet builds use - based on 21.02).
I've asked about the issue in these forums but haven't had an answer, so I thought "well, I'll ask if anyone upstream has any ideas", and wow, do I regret asking for help there. 28 messages back and forth about how "you should just install our firmware" and "it's not really openWRT because they modified the older code to work on the hardware before it was fully supported") I remember that community being a lot friendlier in the past.
Even still, I do like the firmware, and maybe when I have some time, I'll look at moving to the openwrt build. I'll have to set everything up again, which is a shame, because apart from this one little thing, I do really like the GL UI for setting things up easily, and then using luci to set up the things that the stock can't do easily (or at all). Hopefully I won't have to do the same with my Beryl travel router as well, and can just use its built-in wireguard VPN client as-is.
But it does seem that it would benefit gl.inet to be closer to the official builds, possibly to even build their UI on top of the stock firmware so it's got a broader support base.
This will likely not change, the reason is each fork can hold modifications, so when you post a topic there, people are always on the look if there is a bug that could caused your issue, but because it can be changed or have other symptoms, this is why they sent you back to here, the last what they want is take hours for searching a solution or fixing something what introduces something else, even with simple questions I understand they refuse because otherwise they have to allow others too with a different fork.
Only in rare situations it is possible if you can show the modifications (via GitHub) and these modifications are not part of the issue, like getting a deeper understanding of DSA.
Yeah, I'm not surprised now by that. I was just surprised at the unwillingness to even consider providing some help or a direction.
I think I've worked out a solution now - but figuring out how to get it to persist is looking to be a challenge, because the custom rules don't seem to be working the way they're supposed to.
The solution that I've come up with, though, is essentially what I was hoping they could help with - a set of firewall rules that mimics the behavior of NAT loopback. But I'll post an update in the topic here with what I've found that works if I run it manually.
