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.