Using OpenWrt 21.02-rc3, but I think I may have seen this with 19.07 as well...
I flashed the factory image onto my router, and connected via Ethernet, went to http://192.168.1.1 and got the LuCI interface as expected. It contained the familiar "No Password set!" message (see below)
Bug report: There is no way to log in via LuCI. Clicking Login simply returns you to the page,
Workaround: ssh'ing into the router as root (it's OK to use an empty password) lets you set a password. You can then enter that password into the LuCI page and log in.
Workaround #2: After changing the password with ssh, I still could not log in using Firefox (which I had used for the initial login). I had to use a different browser to log in with the new password.
While I totally understand the reasoning, I fear this is not going to happen (obvious disclaimer, I'm not an OpenWrt developer nor too familiar with luci's codebase) - there are just too many variables that could interfere (theme no longer present in the new version, http vs https, openssl vs wolfssl, lua based vs javascripts, etc.). The first problem would be identifying what (probably-) cookie (or http redirect) is actually a problem here (and that might not necessarily be a recent one, but could rather stem from rather dated attempts, as browsers tend to cache especially redirects very persistently).
There may be a lot of variables, but the problem is simpler than that. This occurred with the initial flash from factory firmware to OpenWrt.
This is a newcomer's very first introduction to OpenWrt. Someone would have screwed up their courage to take their already-working router, and install this "open source" stuff.
It was a complete failure. Log in not possible, the router wouldn't do anything except show the login page. If I hadn't been using OpenWrt for the last 10 years, I would be wondering how to get back to the factory firmware.
This case (flashing over factory firmware) must work, first time, every time.
E.g. mt7621/ mt7622 are relatively close to 'normal' OpenWrt underneath (Mediatek SDK using modified older OpenWrt variants, similar things are happening for QCA/ QDSK derived devices, although at least the larger vendors do often replace the webinterface there rather brutally). Depending on what the vendor firmware does underneath, it might do something akin to normal sysupgrade (keeping settings over the upgrade <-- clash between proprietary settings and normal luci) - in which case it's rather difficult to 'fix' this (even renaming the cookie would fall flat with the next SOC, when they've resynced with a more current OpenWrt). I'm just saying keeping track of these client side issues is rather difficult, especially if you (need to) access a device by IP (rather than hostname) - 192.168.1.1 is commonly used by a lot of devices by default (not just OpenWrt). I don't see how this could be fixed, really fixed and not just deferred for another time (renaming the cookie).
This clean install 192.168.1.1 login problem isn’t new with 21.02. Before it has shown up as not loading the login page at all.
If you change computer the problem is gone. Actually I have only had this problem on Windows 10, on all web browsers.
I have tried all variants of cookie flush and what ever it is called without success.
It sometimes feels that Microsoft doesn’t like us?
I have usually gone past the problem before by changing IP address on the router with serial and UCI and then everything works.
Can’t we just change the first install preset IP to some “non toxic” IP?
The problem is that any IP (subnet) will become toxic within short time (e.g. AVM and 192.168.178.x), so better stick to the range that has already been burned.
This problem was actually the reason I learned how to use the UCI interface to begin with. There is some forum tread waay back about this in my time line.
I'm not saying there shouldn't be an attempt to improve current user experience, but shouldn't opening the router's WebUI in incognito mode resolve this issue?
I don't buy it... Surely this cannot be. We're smart people. We can figure this out.
Some criteria we can use to distinguish this case and provide corrective action:
Newcomers (and beginners) only flash routers occasionally. Can the sysauth cookie expire?
Does the sysauth cookie go away when you close the browser window? Our documentation and LuCI page can instruct the newcomer to do so
Is there a special URL that we could place on the first web page (the one that says, "No password set!") that circumvents this?
Could separate sysauth-http and sysauth-https cookies to get around this?
What's special about the 192.168.1.1 address? I note that after I change my router's IP (say, to 192.168.249.1), I can log into it either with http or https...
Because afaik that's what the sysauth cookie is for, to block logins on http if you have used https in the past to connect to this address
Imho this is one of the reasons why disabling the redirect to https
so that they could integrate https support in default images was a bad idea
If the redirect was working, you would be redirected to https and everythign would be fine
(you can try the commands listed in the commit message from ssh so that you get redirection back on first boot and see)
but no, no there is people that must connect with http for some reason even if the system has https by default and everything made in the last decade can connect to https
That's an interesting question. If it works, that URL should be present in the "No password set!" <div> on the login page.
PS I share your concern about the addition of the HTTPS redirect. But that ship has sailed, it's a fait accomplit, the horse is out of the barn, etc.
We will need to update the Quick Start Guide with a note about HTTPS, stating that they should ignore the DANGEROUS! Untrusted site! warning the browser pops up. And then explain how they should never click "OK" when they see this unless they are absolutely sure it's their router they're connecting to... Thanks.
The point to keep in mind here is that you had the issue because you connected over https in the past, and this set the sysauth cookie in your browser. New users (the ones most likely to be following that tutorial) will probably not. So you can just add the "clear the cookes" instructions as a troubleshooting step, it won't be a very common issue.
As for the https connection with the browser warnings, I think it's better to make a separate page about it because it's not the "default" yet and will not be for a while.
The LuCi "sysauth" cookie is marked "Secure", if the login happens via https and the "Secure"-flag on the cookie is not set (obviously), if the login happens via http. (That is security best practice: Secure-marked cookies are not sent over http)
The LuCi "sysauth" cookie is further flagged as "Session" type, meaning it gets auto-removed when closing the browser. So the cookie gets always removed, even if the user is too lazy to actively click "Logout" in LuCi. Session-cookies are not persisted to disk, they just live until the browser session ends.
But ... there might be a single not so obvious situation where this session cookie is not cleared and is still lingering around and causing a conflict.
The following is just a quick theory so far:
User has a browser open with the old vendor firmware GUI, logs in the old firmware via GUI, flashes the OpenWRT image from within the vendor firmware GUI
then without closing/reopening the browser, the user reboots the router (which now has the OpenWRT image installed)
the user then edits the URL line of the still open browser window, calling http// 192.168.1.1 of LuCi. And because the browser window is still open, the old session cookie from the vendor firmware would then still be there, if the old firmware was also using a cookie named "sysauth" as session cookie. If the old firmware was also using 192.168.1.1 there the old cookie will be sent to LuCi, as the old cookie is still there and associated with the domain "192.168.1.1".
Now since I cannot reproduce it with my equipment, it could be one of several issues that happen in such a case:
it could be that the previous login was over https and the new login is non-https (or vice versa), so there might be a conflict arising with the Secure-flag mismatching. I do not know, what the browser and LuCi does now with the existing cookie and LuCi trying to set a cookie with differing Secure-flag.
it could also be that LuCi is just confused about an incompatible session cookie format of the still present cookie, which obviously was not issued by itself, but by the previous (vendor) firmware. (...and wasn't the session expiration added to LuCi in a not so distant past?)
LuCi might not have error handling code for such a situation (as there was no need to do so until now):
A simple fix would then be to tell the user to actively close the browser and reopen the browser after flashing firmware, before the first OpenWRT login, to actively clear the session cookies.
Of little help might be, if the LuCi firmware flash button removes the current session cookie from the browser session, once flashing starts. But it will take ages until this gets taken over by custom firmware.
LuCi could check, if the cookie is missing or seems in a non-expected way on a click on "Login", asking the user to close/reopen the browser as fix.
But I to emphasize: this is all just a theory. I have not verified it.
Might be helpful in the first step, to actually confront LuCi with a stale old token, to see what the actual cause is.
Just to be clear, this is a problem with the user's browser - not an issue with OpenWrt itself. While the sysauth cookie might be possible to work around, that just defers the issue 6-48 months down the road, when vendors (respectively their SDKs) have synced up again.
What can't be fixed at all are http redirects (and no, incognito mode won't always help with those either), browsers are very eager to cache those silently (without an option to delete them selectively) - and their usage is very wide spread in proprietary firmwares as well (I think I first fell over these with a Samsung SMT-G3200 ADSL2+ modem almost 15 years ago).
The issue is caused by Browser heuristics. If LuCI's sysauth cookie was served via HTTPS in the past and OpenWrt is reflashed to a non-HTTPS version, logging in via HTTP will fail as long as there still is a HTTPS-set sysauth cookie remaining from the previous installation as Browsers will refuse to overwrite an HTTPS originating cookie with one served via HTTP.
I was pondering with the idea of accepting either sysauth or sysauth_https cookies in LuCI and set them depending on the HTTPS context (if logging in via HTTP, set sysauth, if logging in via HTTPS, set sysauth_https). But -ENOTIME so it likely won't happen anytime soon.
