Came across another thread while trying to troubleshoot this issue at HH5A - LuCI stops working after changing subnet, but for some stupid reason, the thread is locked and isn't accepting replies even though the issue isn't fully resolved. The final post reads:
I have found a solution. By using turning off HTTPS redirect in uhttpd settings, and using incognito mode in chrome, I can access the HTTP site. The HTTPS site does not work at all.
Also, I do not understand why, but firefox, or any other browser, does not work. Even in private browsing mode.
If anyone has any ideas why this happens, please post your thoughts. My issue may be solved, but I don't necessarily need HTTPS. Others may need / want SSL.
I'm making this thread because I encountered the same issue and ultimately figured out why. The px5g-mbedtls package is missing which causes uhttpd to (silently) fail to create /etc/uhttpd.crt and /etc/uhttpd.key. To fix this, run the following commands:
opkg update
opkg install luci-ssl px5g-mbedtls
/etc/init.d/uhttpd restart
After restarting uhttpd, the console should print something along the lines of:
# /etc/init.d/uhttpd restart
4+0 records in
4+0 records out
Generating EC private key
at which point, uhttpd should respond to HTTPS.
That thread is from 2020. That's half a decade and 3 major releases of OpenWrt. It's better to discuss in a thread that targets a relevant version of OpenWrt.
I didn't go back and read the earlier thread, but I am quite certain changing the subnet will not cause LuCI to fail (http or https). All of the necessary packages should already be installed in a normal/default image of OpenWrt.
What version are you using? Prior to your fix, did you have any other packages that you had added/removed relative to the standard image?
That's open to debate, but I'm not really interested in beating a dead horse. Perhaps I'm biased and this is the rare exception where that axiom isn't true.
OpenWrt 23.05-SNAPSHOT r23001+886-38c150612c / LuCI openwrt-23.05 branch git-24.148.43905-2891ca4. This is the latest available version for my device at the moment (Cudy WR3000H v1)
No.
Try this:
Note that it is also snapshot, so you'll need to reinstall LuCI. Also, I would recommend that you allow the device to reset to defaults during the process since your old config may not be compatible.
I downloaded / flashed the firmware image earlier in the week from the same location and didn't get around to configuring it until tonight -- looks like the snapshot release has update since. In my case, r23001 is working fine for me (and LuCI worked out of the box). I'm content with waiting to see if support for it is added in 24.10.2 and upgrade then.
I only opened this thread because I figure someone else will run into this same issue some day and I was bothered enough by the original issue not being fully resolved to open a follow up thread (running uhttpd / LuCI HTTP only is a terrible workaround at best).
Did the current snapshot work as expected when you changed the subnet (i.e. LuCI didn't break; no additional packages or configs required aside from the general installation of LuCI because it's a snapshot)?
Other than having to switch my browser protocol to HTTP on my client device after making my network changes, yes. Even though it was a snapshot image, LuCI was already working and listening on 80/443 after flashing the r23001 snapshot. Maybe this is because LuCI is already installed in the intermediary image signed by Cudy (details in this commit https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=9d66b8b312fb6a4087244ee3ee10e1ba1623df81)? I didn't have the device connected to the internet prior to discovering this issue because I was making all of my necessary network/dnsmasq configuration changes so it would be a relatively quick and easy drop-in replacement.
I'm making an educated guess that the network configuration changes caused the certificate files to be deleted so they're automatically regenerated by uhttpd when the service restarts, but since px5g wasn't installed, that wasn't happening and caused HTTPS to break. Once I discovered the cert files were missing, I tried to manually create them with px5g, which is when I discovered the binary wasn't installed and subsequently learned uhttpd is supposed to auto-create them if they're missing.
I ended up swapping the device in with only HTTP working and once it had internet access, I resolved this issue as described in my first post.
If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks! 
It is probably worth mentioning here a couple of points about snapshots and the Firmware Selector (FS).
- the prebuilt snapshot images from FS do not contain Luci.
- If you use FS to customise your snapshot image, Luci is included by default in the custom build.
- BUT px5g is NOT included. If you want https you have to add it to the "Installed Packages" list.
Is this an accidental omission from the standard list in custom FS? Probably.
I used to ask a similar question, and the answer was to install the luci-ssl package, which solved this problem
1 Like