have you tried to find a solution on this forum? If you are using the snap version and now you can't log in because the password doesn't work, then the solution is a few posts above!!!
Bah i'm not satisfied for this router and i use 1/8 of the router function , updated to 4.8 v4 wireless schedule doesn't work , udpated to V6 and set to stop wifi from 09 am to 09.30 am (Just For test) and wifi stopped to work from 09.30 and never give up, renabled via ethernet now i can't enter in router settings via WiFi for admin password incorrect (that's impossibile ) probably cause i'm already logged via ethernet and instead to say already connected give login password errore
I Will give a try with firmware reset asap
(Edit) See the problem Is in the glinet app
hi， This is a known isssue that occurs when you enable "Force HTTPS".The latest beta version released on June 14 has fixed this problem.Could you please upgrade to this version and try again?
1 Like
I'm sorry for the inconvenience. This issue occurred because we implemented a more secure encryption method for the login API. The updated app, which is compatible with this change, is currently being tested. We will do our best to release the latest version as soon as possible.
2 Likes
In a previous commit, I made a mistake by placing the code for generating VPN group rules before the firewall rule cleanup. As a result, the rules were written but then immediately cleared.
Thank you for pointing this out.
good catch! So sharp!
You can use the following commands as a temporary solution:
sed -i '/setup_instance_via.lua/a\main' /usr/bin/rtp2.sh
sed -i '/Configuring iptables rules/{n;d}' /usr/bin/rtp2.sh
2 Likes
I've got this issue too - and there a new thread.
It was working but I later noticed is had stopped after reinstall 4.8.0 beta. This was before the new beta on 14th June which also does not work with the VPN list.
Just got the android app update and the login is fixed now. Thank you!
Thanks for the quick fix, works perfectly now!
There's also a bit of an issue in the luci interface, I'm not sure if I'm the only one encountering it, in system > administration> 'ssh interface', checking or unchecking "Allow root logins with password" doesn't seem to work, hence ssh access doesn't work, changing manually '/etc/config/dropbear' fixed the problem.
Hi,
I have forwarded this issue to the relevant colleagues and they will locate and fix it.
Thanks for your help.
Yes. Everything is fine now with beta6. Thank you!
Hi again @teleney
It looks like the issue is fixed on the latest snapshot (2025-06-16). Thank you.
1 Like
My bad, ssh wasn't enabled.
But I think you should let the user know about the risks and let him decide if he still wanna use a weak password instead of forcing him to do so in order to get to use ssh.
Maybe only enabling 'Remote Access' should force the use of a strong password
I'm having an issue on the Flint 2 with 4.8 beta release 6. I noticed that when running the VPN the IP address that is being reported to my DNS (nextdns and controld) they are seeing requests from my actual ISP IP address and not the VPN. This was reporting properly in the previous beta 3. When access sites or other functions it appears to reporting the VPN IP, but I'm concerned that the real IP is leaking somewhere. Any assistance would be appreciated.
I also updated to the latest release for the snapshot and still see the same results. I’m hoping there is a change I could do that would resolve the issue. Thank you
Hi,
In order to divert encrypted DNS requests according to the policy, we established two connections with the encrypted DNS server.
One connection is established using the VPN channel. DNS requests that meet the rules of using VPN will use it to request services from the encrypted DNS server.
Another connection is established using the WAN. DNS requests that do not use VPN will use it to request services from the encrypted DNS server.
Therefore, it is necessary to use the WAN IP to communicate with the encrypted DNS server, so the encrypted DNS server can get the WAN IP.
I have it set to override the VPN DNS settings to I can use my DNS provider (ControlD) but I see all traffic reporting the WAN IP and not much if anything is using the VPN IP. Is this a new behavior? As of 4.8 Beta 3 this was not the case and seems to have recently changed. I do see sites reporting the VPN address, just seems to be acting differently then previous versions, so I would like to make sure this is accurate and if there is a way to have the encrypted provider to receive the VPN address instead of the real address? I can send you a screenshot of the DNS settings if that would be of benefit.
I think that the encrypted DNS server can obtain the WAN IP, which is not a leak, because in order to resolve the domain name of the website that does not use VPN, we need to communicate with it using the WAN IP.
Of course, I will forward the content you mentioned to our internal department for discussion.
Make sure that all DNS in the router's internal network use VPN. You can try to execute the following code in the router terminal:
sed -i '/\/etc\/init.d\/stubby-vpn start/a \/etc\/init.d\/dnsmasq reload' /etc/init.d/stubby;
sed -i '/\/etc\/init.d\/stubby-vpn start/a uci commit dhcp' /etc/init.d/stubby;
sed -i '/\/etc\/init.d\/stubby-vpn start/a uci -q set dhcp.@dnsmasq[0].localuse=0' /etc/init.d/stubby;
sed -i '/\/etc\/init.d\/stubby-vpn start/a ln -sf \/tmp\/resolv.conf.d\/resolv.conf.auto \/tmp\/resolv.conf' /etc/init.d/stubby;
Then restart the router, which may meet your requirements.