Bug or not? Need advise

pwned · July 27, 2026, 12:42pm

0.) I didnt search much if those "bugs" are known already and/or reported. So you can bash me for this. So just let me know if this are considered as bugs and worth to report.

1.) Theme Material is not working since a while. Its always black colored regardless what I choose (Material, Material Dark, Material Light). I don't know if this theme is not supported anymore.

Temporary fix (uci-defaults file):

THEME_DIR="/usr/share/ucode/luci/template/themes"
STATIC_DIR="/www/luci-static"

[ -d "$THEME_DIR/material" ] && [ ! -e "$THEME_DIR/material-light" ] && ln -s material "$THEME_DIR/material-light"
[ -d "$THEME_DIR/material" ] && [ ! -e "$THEME_DIR/material-dark" ]  && ln -s material "$THEME_DIR/material-dark"

[ -d "$STATIC_DIR/material" ] && [ ! -e "$STATIC_DIR/material-light" ] && ln -s material "$STATIC_DIR/material-light"
[ -d "$STATIC_DIR/material" ] && [ ! -e "$STATIC_DIR/material-dark" ]  && ln -s material "$STATIC_DIR/material-dark"

if [ -d /www/luci-static/material ]; then uci set luci.main.mediaurlbase='/luci-static/material-light' && uci commit; else uci set luci.main.mediaurlbase='/luci-static/bootstrap-light' && uci commit; fi

2.) I have two routers connected to an upstream router via WAN. Firewall is on -> NAT. To reach LuCI via upstream router firewall is opened for port 80 and 443. The WAN IP is added into uhttpd. So I have e. g.:

uhttpd.main.listen_http='10.1.1.1:80' '192.168.178.250:80'
uhttpd.main.listen_https='10.1.1.1:443' '192.168.178.250:443'

But as soon I do so uhttpd becomes "unhappy" on boot:

Mon Jul 27 14:09:22 2026 daemon.err uhttpd[4485]: bind(): Address not available
Mon Jul 27 14:09:22 2026 daemon.err uhttpd[4485]: bind(): Address not available
Mon Jul 27 14:09:24 2026 daemon.err uhttpd[6783]: bind(): Address not available
Mon Jul 27 14:09:24 2026 daemon.err uhttpd[6783]: bind(): Address not available

So sometimes it pick's up the WAN IP sometimes not. On one router it never pick's it up and the router cannot be reached over WAN IP. I have to restart uhttpd manually. So its kind a race condition.

I don't know if this is an supported configuration.

Temporary fix (iface hotplug script):

#!/bin/sh

[ "$ACTION" = "ifup" ] || exit 0
[ "$INTERFACE" = "wan" ] || exit 0

for i in $(seq 1 10); do
ip=$(ubus call network.interface.wan status | jsonfilter -e '@["ipv4-address"][0].address' 2>/dev/null)
[ -n "$ip" ] && break
sleep 1
done

[ -n "$ip" ] && /etc/init.d/uhttpd restart

Not ideal but it works.

3.) I'm running several DNSmasq instances since this was made possible on OpenWrt. Its one of the highlights on OpenWrt (compared to professional router software) which i like very much.
It runs very stable since a while now. For the record here I bind all instances to a seperate network and their corresponding network IP. Three of them are IPv4 only. Main network (default) is running both. I end up always with sth like this:

tcp        0      0 fe80::dd09:ebd4::df25:53 :::*                    LISTEN      10543/dnsmasq
tcp        0      0 fe80::dd09:ebd4::df25:53 :::*                    LISTEN      10542/dnsmasq
tcp        0      0 fe80::dd09:ebd4::df25:53 :::*                    LISTEN      10234/dnsmasq
tcp        0      0 fe80::dd09:ebd4::df25:53 :::*                    LISTEN      10235/dnsmasq
tcp        0      0 fdff:47dd:a746:b:2d0::fe04:4fa8:53 :::*                    LISTEN      10235/dnsmasq

Is this expected/normal or is it an issue? Why isn't it enforced for ipv6 like for ipv4?

psherman · July 27, 2026, 5:12pm

You didn't specify the device and version of OpenWrt.

This theme is working for me on 25.12, no changes necessary. Did you make any other modifications?

pwned:

Firewall is on -> NAT. To reach LuCI via upstream router firewall is opened for port 80 and 443. The WAN IP is added into uhttpd. So I have e. g.:
uhttpd.main.listen_http='10.1.1.1:80' '192.168.178.250:80'
uhttpd.main.listen_https='10.1.1.1:443' '192.168.178.250:443'
But as soon I do so uhttpd becomes "unhappy" on boot:

It's not clear what you're trying to achieve here with the firewall, but don't change the listen address. leave it at 0.0.0.0 which will allow it to listen on all addresses.

If your firewall goal is to allow LuCI to be reachable from the upstream network (NOTE: only do this when the upstream is considered trusted; never do this if the upstream is untrusted such as a direct connection to the internet), create a rule to allow input from the wan zone on ports 80 and 443. Or alternatively, if you want to allow full access to the router itself from the upstream, change the wan firewall zone to ACCEPT input (again, only do this if the upstream is fully trusted).

pwned · July 27, 2026, 5:30pm

Sry, forgot to mention I'm running snapshot.
EDIT: No I didn't modify anything else regarding the themes.

Well I tried to avoid allowing guests/iot lan to access luci while reaching smb service running on a specific router. Otherwise input reject on the zones would be sufficient I think. This lans are more or less allowed to fwd to wireguard internet only and some services within other lans/and smb running on the router itself. I'm aware thats prop. not ideal. But the threats here comming from guests are not that huge.
EDIT: I'm aware I could deny fwd. to the device and allow specific ports to reach. But that was the easy approach. ;D

psherman · July 27, 2026, 5:43pm

It is possible that there is an issue with the theme on snapshot, but keep in mind that snapshot is, by nature, not considered part of the stable releases and may have transitory bugs and/or other breaking changes that may (or may not) need to be addressed by package maintainers.

Is there a reason you need or want to use snapshot?

Use the firewall to set access control. The listen address does not actually limit access, it just sets that address to which the service will respond, much like a name...

The analogy is that of a name... anyone on the forum can invoke your name @pwned and you'll get a notification -- treat this like the listen address. It doesn't matter who they are, they can mention you. However, let's say you had a conflict with one or more users -- there are forum software features to block specific users that you can use to block notifications originating form those people. This is what the firewall does.

The firewall to deny/allow is the correct appraoch.

slh · July 27, 2026, 7:25pm

In general, only 'bootstrap' and 'openwrt2020' are considered fully supported themes, the others are on a 'best effort' and 'patches welcome' level. Themes open up considerable complexity and unexpected permutation, which require constant testing and fixing, but developer ressources are finite, so the primary focus is on those two.

pwned · July 28, 2026, 8:47am

No specific reason for running snapshots. I run always snapshot since I know OpenWrt. Which means to self-fix/workaround things often. But its O.K. So I thought I could report some "bugs" bc. I have some time left. But as usual you never know it if its a real "bug". That's why I asked here before.

Y, I know. I still wonder why this option is available. Anyway its not supported. So no bug.

I didn't know this. Because I use this theme for years now with almost no issues.
So if I would like to fix this. Could I create a bug report or a PR against:

github.com/openwrt/luci

themes/luci-theme-material/root/etc/uci-defaults/30_luci-theme-material

openwrt-25.12

#!/bin/sh

if [ "$PKG_UPGRADE" != 1 ]; then
	uci get luci.themes.Material >/dev/null 2>&1 || \
	uci batch <<-EOF
		set luci.themes.Material=/luci-static/material
		set luci.main.mediaurlbase=/luci-static/material
		commit luci
	EOF
fi

exit 0

just to create those links if not exist? I know this is not ideal and just a hack. But as I can see this theme is dead or not activley maintained anymore.

1.) + 2.) are solved.

hnyman · July 28, 2026, 10:15am

The light / dark mode support for the Material theme is a new thing, just two months old from PR

github.com/openwrt/luci

luci-theme-material: add dark mode support (#8551)

master ← MagmaiKH:magmaikh/material-dark-mode

opened 01:44AM - 13 Apr 26 UTC

MagmaiKH

+206 -87

## Pull Request details ### Description Add dark mode following the luci-the…me-bootstrap pattern: auto-detect via prefers-color-scheme, with forced MaterialDark/MaterialLight variants. Replace ~60 hardcoded colors in cascade.css with CSS variables and override them in a :root[data-darkmode="true"] block. ### Screenshot or video of changes _(If applicable)_ <img width="2560" height="1440" alt="image" src="https://github.com/user-attachments/assets/600ea3d6-a420-4cff-bc8c-a681ee639510" /> ### Maintainer _(Preferred)_ @systemcrash --- ## Tested on **OpenWrt version:** 24.10.6 **LuCI version:** 24.10 **Web browser:** Firefox Chrome --- ## Checklist - [✅] This PR is not from my *main* or *master* branch :poop:, but a *separate* branch. :white_check_mark: - [✅] Each commit has a valid :black_nib: `Signed-off-by: <my@email.address>` row (via `git commit --signoff`). - [✅] Each commit and PR title has a valid :memo: `<package name>: title` first line subject for packages. - [N/A] Incremented :up: any `PKG_VERSION` in the Makefile.

Quite possible that the author of that functionality has forgotten something.

Your addition of the symlinks looks sensible at the first glance.
The proposal about mediaurlbase option looks wrong, as there may be several themes installed, and material and bootstrap are not the only possible choices.

@systemcrash merged the feature, so he might have some insights from his testing.

pwned · July 28, 2026, 11:23am

Ah, I thought that its dead. Nice its not! So its more a WIP. As I saw it first I was a bit confused bc. in part it was not readable and I thought the addition within dropdown menue it just a mimic of bootstrap settings.

I dont know anything about how this is working (eg. if it inherents parts of bootstrap to make this work or not). So I just mimicked whats there for bootstrap. But it seems that no other has issues with it. So maybe the issue is on my side? oO

lleachii · July 28, 2026, 11:51am

Not clear the "option" you're referencing.

If you're referring to changing IP and port of uhttpd, there are a few things:

pwned:

The WAN IP is added into uhttpd. So I have e. g.:
uhttpd.main.listen_http='10.1.1.1:80' '192.168.178.250:80'
uhttpd.main.listen_https='10.1.1.1:443' '192.168.178.250:443'
But as soon I do so uhttpd becomes "unhappy"

your configuration added these additional IPs to the existing 0.0.0.0 (and IPv6 equivalent). Hence your OpenWrt was unhappy, as it was already assigned to that interface (or rathar, bound to all IPs) - I wanted to be sure the "support" discussion was highlighted as being distinct from the configuration error
The listen config can be used for many reasons, for example a second uhttpd instance as a web server (also not recommended)
but for the use case you describe (i.e., just making LuCI unavailable on an interface), the firewall is recommended in general

pwned · July 28, 2026, 3:42pm

Ah thats explaining it. Thx for this clearification. Didn't understand that this behaviour is not stopped if an address is explicit given.

systemcrash · August 2, 2026, 5:59pm

If this doesn’t receive a PR I’ll consider reverting this.

pwned · August 3, 2026, 8:54am

I have no insight were to fix this. If its allowed to add the "hack" from above into 30_luci-theme-material setup I could create a PR.
Beside this. The black theme has some issues regarding "readability". So it would need a bit rework. If the creator of the PR is still engaged.

lleachii · August 3, 2026, 9:15am

Interesting - mine doesn't appear that way:

pwned · August 3, 2026, 9:40am

I have no clue why it looks like this. On Bootstrap Dark it looks like you have it but for Material Dark it looks like on my Screenshot. I tested with Firefox and Chromium no diff. But I could imagine its a diff between Linux and Windows. I don't run Windows. Cannot even test it. xD