Traveling with this (Beryl) router. Every time I arrive at a new location, I connect to the router's 192.168.8.1 Wifi and load the admin panel in my browser (which is Firefox on Windows 11). I enter my previously configured admin password, but the router rejects this as "invalid username/password" (or similar wording). The password is certainly correct.
To recover from this I have to reset the router and use the default password to regain access; then I set my own wifi and admin passwords and I am in to the admin panel. But my Wireguard config is lost and I have to enter that again.
This has happened three times and only happens when I move location. I suppose that the router is trying and failing to connect to the network of the previous location, but I don't understand why that prevents me from logging in. I am using wifi only, not wired Ethernet.
its happen to me even if i dont move the place. I put a Admin password and when i try to use it. Password invalid even if i try directly to change it after de reboot/config. OLD PASSWORD INVALID
I am running v4.7.4 (upgraded from 4.7.3 or 4.7.2 a few weeks ago). I have been avoiding 4.8 because I see a couple of posts in this forum warning of some problems with it.
I have now downloaded the phone app and I will try that the next time. I have already gone through the trouble of re-configuring the router for my current location and I don't want to disturb it with further troubleshooting right now. But this is a good thing to try next time.
Do you maybe use special symbols which causes this?, something different than the utf-8 charset ?
just to be sure, you don't use a usb stick as storage device right, as a ext4 overlay?
otherwise if it is the ext4 storage, this is normal... because you overlay the space, if you remove the usb basicly you reset to the state before you modified the overlay, and it can sometimes be pretty dangerous with packages too having a potential to cause soft brick if litterly mounted as /overlay, because when you perform a firmware upgrade then the usb packages overlay the newer core packages with the old outdated ones.
I still haven't been able to fully characterize it or reproduce it. Shockingly, I was bitten by the same bug on vanilla OpenWRT in the past couple weeks, so finally I know it's not GLi's fault
Possible workaround:
If you are connecting to the admin panel via https, connect via http; if you are connecting via http, try https. The password may work again after you switch protocols. You can then reset the password from the web interface, after which it will work again normally.
You may be able to connect via ssh; I don't remember if passwd then resets the password successfully or not.
Unfortunately this bug bites me only about 1 to 2 times per year, so progress has been very slow on figuring out how to reproduce it so it can be fixed ... and my recent experience indicates that it may be in OpenWRT itself, not GLi's code.
No, my password is UTF-8 characters only (and it works all of the time except for the first attempt after moving to a new host network).
I do not have any special storage devices. The router is completely 'out of the box' standard except for the OpenVPN and Wireguard clients (to NordVPN) that I configure.
The issue is I have a hard time following this, what happens on the view exactly?
If you get this issue, are you sure that you are connected to the correct wireless AP and don't see a cached offline page?
I know as example that some browsers do this like Brave, it sill show a identical offline page, but inputs will not work until there is internet ..., but that will fail if the AP mismatch.
The error, is written in javascript which renders completely cliënt side, it could be that this error has been shown as fall back when it couldn't communicate with the gl sdk api from the ui, although if that is the case, @bruce could you ask the developer team to make error for this specific case?, when the ubus/rpc api call fail from a offline cached JavaScript?
^ to add sometimes it works forcing a reload with F5 it will often be more clear if the page is offline, although some browsers keep caching.
But it can also be a defect where the chips runs out and becomes read only, but that is not random, it will constantly do it with 100% failure on each re-power.
From my own experience I see this non chip issue happen when I have 2 networks saved on my Android, one main network and one travel router i.e MT3000, and when I set the MT3000 to repeater mode, due to the nature of going offline if it repeats on the same band where I was connected on, my android connects automatically to my main wifi instead of the MT3000, but in Brave my router page keeps cached, and even when reconnecting to the MT3000 I sometimes have to do a F5 on the cached page to make sure it connects.
Best is to disable automatic connecting to wifi networks on the android device/client
Hi,
There are a few reported cases of this issue, but they occur sporadically and are unstable to reproduce.
First, ensure you have a valid connection to the correct router (via WiFi or wired).
The cause has not yet been determined.
In this case, we can try to add a special prompt, but the prompt for incorrect input of ordinary passwords will remain unchanged.