Luci unable to log in on SNAPSHOT for specific device model

Got a bit of a weird one going on with a couple of new Asus RT-AC58U (ipq40xx) devices -- luci refuses to allow me to log in. Flashed them with the latest snapshot build, set the password, and apparently there's no ubus response for a login request from luci.

Using the same user/pass combo to log in via SSH works perfectly fine, so there's no problem with the authentication parameters themselves.

I've also got an x64-based OpenWrt install with similar-age revisions installed, and the log from running ubus monitor does indeed show responses to the login request, and I get a proper ubus_rpc_session response.

Anybody know off-hand how this would stop working? Was there some sort of recent communication change? Any ideas on what I should be investigating next?


Current version string on the Asus RT-AC58U (ipq40xx): "Powered by LuCI Master (git-18.138.35484-521554f) / OpenWrt SNAPSHOT r6952-5399de754d"
Current version string on the x64: "Powered by LuCI Master (git-18.136.23288-7b68436) / OpenWrt SNAPSHOT r6951-22c16c5"

snapshots do not come with LuCI preinstalled.
https://openwrt.org/releases/snapshot

I understand. These devices have luci installed.
This isn't an issue with a lack of luci being available -- the issue is that the normal luci login screen is failing to create an RPC session with ubus. The web interface starts up fine.

Is an ubus call session login '{ "username": "root", "password": "..." }' working correctly, do you get a proper session response there?

Also do you have proper ACLs staged in /usr/share/acl.d/? Is should contain a file luci-base.json granting access to the login procedure for the null session.

On the x64 machine I get a successful response.
On the RT-AC58U, I get: "Command failed: Permission denied"

I've compared /usr/share/acl.d/luci-base.json on both machines, and they're identical. Anything else worth checking?

Run the ubus command using strace to see if there were any permissions issues, nothing that I could find with respect to the fd's being touched by ubus itself. Permissions on /var/run/ubus.sock are 0666/srw-rw-rw-.

So I've tracked down the problem - for some reason the contents of /etc/config/rpcd is being removed after an update and/or factory reset.

/rom/etc/config/rpcd does indeed have the original, expected content, the one in the overlay is blank.

I'll muck about with the 3rd device to track down the cause and/or timing.
I've got a feeling that this is related to the whole sysupgrade not wiping ubi volumes by default, despite using the "don't keep config" argument.

I have the same issue with Gateworks Ventana board. Building SNAPSHOT image with Image Builder. At first boot all file are in place but after the first reboot - files are empty (/etc/config/network /etc/config/rpcd ...) . But files are in place in /rom

I just ran into this issue while installing OpenWRT 18.06.1 on a new Netgear R7800. After using the factor reset button both /etc/config/rpcd and /etc/config/uhttpd where overwritten with one line of garbage characters.

At first I couldn't even got a Luci login page, and then, after removing and reinstalling uhttpd to restore the config, I couldn't log in with a similar error. Google pointed me to this page and copying /rom/etc/config/rpcd back into /etc/confg/ fixed my login error as well.

Yeah, I ended up adding a line to the end of my auto-deployed /etc/rc.local:
[ "$(cat /rom/etc/config/rpcd)" == "$(cat /etc/config/rpcd)" ] || cat /rom/etc/config/rpcd > /etc/config/rpcd

Unfortunately it won't help you unless you're building your own image, and include that.

When I investigated, it looked like the issue was the fact that jffs2reset wasn't capable of unmounting the overlay, and instead of nuking the UBI volume, it just deletes the files instead.
Seems like there's an inconsistency and it decides to reference garbage on the flash at that point.