Suddenly, GUI won't accept long-standing username/password, but SSH does

[bpsmicro]

BE92U running 3006.102.5 problem-free so far.

But at some point this morning I lost all connection. That in itself isn't super-unusual because my wireless internet can be a bit spotty at times. It *appears* the router self-rebooted, but I can't be sure. A minute later, and all is back up and running.

Except, I can no longer log into the GUI. It just says "Invalid username or password", except I know for sure it's correct. *BUT*, if I SSH in and log in using the same username/password, that works fine.

So the question is, should I just reboot and hope it's all fixed, or will doing so run the risk of now breaking SSH, leaving me totally boned? Or is there something else I can do first while logged in via SSH that'll be a safer fix?

 

[John Fitzgerald]

BE92U running 3006.102.5 problem-free so far.

But at some point this morning I lost all connection. That in itself isn't super-unusual because my wireless internet can be a bit spotty at times. It *appears* the router self-rebooted, but I can't be sure. A minute later, and all is back up and running.

Except, I can no longer log into the GUI. It just says "Invalid username or password", except I know for sure it's correct. *BUT*, if I SSH in and log in using the same username/password, that works fine.

So the question is, should I just reboot and hope it's all fixed, or will doing so run the risk of now breaking SSH, leaving me totally boned? Or is there something else I can do first while logged in via SSH that'll be a safer fix?

ARE YOU obeying the new password requirement as outlined in the change log? Try that, after you gain SSH access.

 

[bpsmicro]

No, because the new rules only kick in if I want to change the password, which I don't. No settings have been changed at all in a very long time.
Plus, I'd have thought the SSH and GUI username/password combo would be the same. Hence the concern.

However, if it's confirmed that the firmware might decide all by itself to enforce the new rules out of the blue, then I guess I'm stuck changing it. :-(

(curiously, I pulled up the changelog for 3006 again, and I'm not seeing the blurb about the password rules. I remember reading it, so it must be somewhere else. I'll find it. Probably in the 3004 changelog.)

 

[bpsmicro]

ARE YOU obeying the new password requirement as outlined in the change log? Try that, after you gain SSH access.

In the end I did a soft reboot and the old password magically started working again. Weird, but all's well in the end.

 

[rickysuperdog]

My BE92u it had happened several times before. Just reboot and the existing password will work again.

Strange....

 

[Zirescu]

Double check the date on the router after connecting via SSH by executing date. You'll likely see that the date is in the 1900's (1918). Why this is happening I haven't tracked down but likely some value is overflowing, and the clock gets clobbered. The only way to resolve it is a reboot as often this will cause issues with your connection to the Internet as well. I ended up writing a script to detect when the date was less than 1969 and force a reboot when it happens.

 

[John Fitzgerald]

Double check the date on the router after connecting via SSH by executing date. You'll likely see that the date is in the 1900's (1918). Why this is happening I haven't tracked down but likely some value is overflowing, and the clock gets clobbered. The only way to resolve it is a reboot as often this will cause issues with your connection to the Internet as well. I ended up writing a script to detect when the date was less than 1969 and force a reboot when it happens.

You could just use the Date Keeper function via the AMTM menu. This maintains the date even if you reboot.
Not sure if your error is caused by something else, have not seen this reported here before.

 

[Zirescu]

I'm not certain Date Keeper would help in this case and might actually make it worse as the clock on the system is getting set back to 1918 and having Date Keeper running and executing the reboot would in theory keep the clock in 1918. When the clock on the router comes up after the reboot it appears to default to 1969. Which NTP can cope with.

 

[lgkahn]

i had the same issue once on my gt-axe16000 running 105.0.. log in would not work.. reboot fixed it.. next time i will check the clock

 

[bpsmicro]

Yeah, there's a relationship between the date getting all wonky and the login failing. If I'm already logged in on the web and SSH, I can see that the processor cores are pegging at/near 100%. Eventually the router will self-reboot. I'm grabbing as much logging as I can during the day while I wait for Amazon to deliver my BE88U, which I hope is better (if not, at least I can return it and drop back the AX line). The BE92U will be delegated to AIMesh duties using stock firmware, which appears all it's good for (hopefully, at least that).

Right now WiFi/LAN/Internet is mostly working, date (via SSH) is May 8, 1918, and I can't log into the web. At some point it'll self-reboot unless I do it first.

Something's clobbering over important RAM, but my attempts to narrow it down aren't yielding much valuable information. :-(