I've experienced this bug once or twice on almost every single GLi device I've ever owned, and I've owned probably more than half the product lineup at this point.
The bug is:
The admin password doesn't work in HTTP when it was set in HTTPS, or some variant of that.
To work around it:
Connect to the router in the opposite mode (HTTP if you were connected via HTTPS, or vice versa), and the password will work.
This was present in 3.x firmwares and is still present in 4.x, it bit me a couple weeks ago on either Beryl AX or Slate AX (I don't remember which).
I just tested in my SFT1200 v4.3.17 and it does not have problem.
I opened a Window of http and a Window of https.
I can login both.
I changed admin password in http window. I can re-login in https window.
I can do it vice versa.
I've experienced this on multiple devices, starting with GL-MV1000 back in 3.x days.
I can't remember which device I was working on when this bug bit me again this month, possibly Beryl AX??
I will try to reproduce it on a couple spare devices when I have time, and nail down exactly when it seems to happen (in my case, usually seems to happen right after I've flashed the device with new firmware). Currently I have a spare Brume 1, Creta, and Slate Plus which I can experiment with.
No, in my case it seems to happen very shortly after flashing a new firmware and then rebooting the router after completing the initial setup in the web UI. Usually I haven't logged in via ssh at all by that time, just used the web UI. (FWIW about 90% of the time when I flash a new image, I tell it not to keep old settings.)
I've almost never reset the admin password via ssh at all. Maybe a handful of times in four years of using many GLi products - ironically, in some cases, after this bug bites.
I'm mostly hot to see if this bug can be fixed because, with the number of times I've experienced it, I'm sure less experienced users must be running into it as well... and in their case, they might give up and end up returning the product. The experience can be maddening because, if you don't happen to notice you're on the opposite protocol (HTTP vs HTTPS) as you were when going thru the initial setup, you'd have no clue at all why the password you just set a few moments ago is suddenly not working.
I'll gather all my spare GLi devices and put aside time to test this and see if I can narrow down further the exact circumstances when it occurs. Because it doesn't always occur (obviously) and I don't know what the difference is when it does.
It does not make sense that there should be a bug containing these issues. As I wrote before, the endpoint (so the part which writes the password) does not even know about https or http only. Nginx will take care of it - and the underlying scripts are not aware about it.
I never experienced this issue with any of my GL devices - and I do have plenty of different models. Presently, I would assume the issue is more the browser than the router itself.
Hey, I'm currently having to move house on short notice, but I haven't forgotten this - I will update when I can get a couple hours to try to reproduce the issue in a controlled manner.
This bit me again today after a factory reset with Slate AX on firmware 4.6.2.
I'm still in the process of moving across the country, so I haven't had time to sit down and characterize the buggy behavior properly. I will do this as soon as I can.
However, I think I might have inaccurately described this as a "password bug" when perhaps the actual bug is that sometimes the GLi web UI is served over http (and not https) shortly after a firmware update or factory reset.
Once this happens, unusual behavior results, e.g. it's not possible to log into Luci with the correct password which one previously set during the firmware setup procedure.