Configuring a default setting for LuCI in a compiled firmware image

Hello everyone,

I'm trying to do some investigation on why there's a problem with LuCI with the Davidc502 firmware - my posts can be seen here:

There is an issue with an unresponsive LuCI interface which can be corrected with the following commands / settings:

uci set uhttpd.main.http_keepalive=0
uci commit
/etc/init.d/uhttpd restart

The question at hand is, what value needs to be changed to have this setting present so it's set by default prior to compiling?

I am not entirely sure myself here, so I'm just trying to lend a hand and seek advice and guidance from the community on how to correct this issue moving forward.

I am not sure why this issue is happening with the Davidc502 firmware as I do not have the same issue with stock OpenWrt 18.06.04 - but as a workaround for now, wanted to see what possible solutions are available.

Thank you!

https://openwrt.org/docs/guide-developer/build-system/use-buildsystem#custom_files

https://openwrt.org/docs/guide-user/additional-software/imagebuilder#files_variable

It could also be done with a "run-once" script in /etc/uci-defaults/ (visible at /rom/etc/uci-defaults/ on a running device).

Edit: As an example, from /etc/uci-defaults/50_luci-mod-admin-full

        uci -q batch <<-EOF >/dev/null
                set luci.diag=internal
                set luci.diag.dns='${host:-openwrt.org}'
                set luci.diag.ping='${host:-openwrt.org}'
                set luci.diag.route='${host:-openwrt.org}'
                commit luci
        EOF

This issue appears to browser / platform dependent, questionable as to whether the default should be overridden.

I do know that one of the differences between Davidc502's build and stock is the inclusion of a different default theme, at-material (based on Advanced Tomato)

Browse wise, I'm using the same browser and OS for both stock OpenWrt and Davidc502 builds:

Chrome Version 77.0.3865.90 (Latest at the time of writing)
Windows 10 x64 (Build 1903)

Other users have also mentioned this in the thread so it isn't just me running into it.

Does it seem plausible for a theme to be the root cause of the issue, or would this setting in question that is deemed a workaround not really matter in regards to a theme?

Anyways, just wondering and looking for advice on how I should proceed or what information to relay back to them for troubleshooting/etc.

Thanks!

Simple way to checking it's the theme is to uninstall it and reboot the router.
Use the stock OpenWRT and report back.

1 Like

I'm using ungoogled chromium (v67, old version) for all my web GUIs and I dont have a problem with the at-material theme, even without the workaround. I guess it's a browser related problem...

OS: Win 10 x64 (1903)
Browser: ungoogled chromium 67.0.3396.87 x64

If I have time later on I'll test the latest version of ungoogled chromium (77.0.3865.90) and see If I can reproduce the problem.

2 Likes

I am fairly sure you can edit /package/network/services/uhttpd/files/uhttpd.config. After compiling the firmware, the setting should be there by default.

Creating a file in uci-defaults seems a bit too excessive for me, especially when you're only changing a single option. (That is, if you want a fix for yourself)

1 Like

Interesting, I've only had a chance to use the latest version and currently went back to stock OpenWrt - so if you get a chance to test with more browsers be sure to report back.

Some similar reports go back to early in the summer - I can see the first time uci set uhttpd.main.http_keepalive=0 was mentioned in the thread was August 6th 2019 here: Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds which also mentions a thread here Proposal (and solution!) for High Load fix on OpenWrt (LuCI) that goes back to Jan 12th 2019

Can you tell me where do you exactly have issues at the Luci?
I did a test with the latest version of Waterfox (56.2.14) and I couldn't tell that there is any issue when navigating in Luci.

The problem was apparent immediately, I noticed it while attempting to load the login screen - sometimes requiring a refresh to get it to work, and then browsing around the LuCI web interface - clicking objects would do nothing or hit a blank page as I recall, requiring me to F5 it once or twice to get the page to actually load. Example: Going into the Switching/Interfaces section of LuCI - but really it was apparently for any new page load for the web ui.

From here:
connection reuse. Some bugs have been seen, you *may* wish to disable this by setting to 0 (BB or later only)