Why is luci dependent on luci-app-firewall?

For Developers
1

I have some devices running OpenWRT that I don't intend to use as firewalls (a managed switch and a few dumb APs), so I wanted to remove the functionality entirely in the firmware selector. Did some looking, and I saw luci depends on luci-app-firewall.

I tried force removing luci-app-firewall, and everything still works fine. Only noticed 3 details so far.

  1. There is still a Firewall entry in the status drop-down, which when clicked, shows a blank page.
  2. The interface configuration view still contains a non-functional Firewall Settings tab
  3. The firewall init script is still in Startup, even after removing firewall4 and nftables. (don't think this one has anything to do with LuCI, but putting it here nonetheless)

All other functionality works as it typically does, and there are no odd messages in the logs.

Is it simply that there are some firewall-specific UI components built into other parts of LuCI that don't work right without luci-app-firewall? Or does this really break something under-the-hood that I'm not aware of?

2

luci-/ luci-ssl are meta-packages, there only purpose in life is pulling in a 'sensible' set of packages that make up a route, which includes a firewall - but crucially they don't provide any functionality on their own.

2 Likes
3

This is part of luci-mod-status. You can manually remove these files and see if it disappears:

/www/luci-static/resources/view/status/nftables.js
/www/luci-static/resources/view/status/iptables.js
1 Like
4

I would generally recommend against this. Simply stated, it's an unnecessary step and may cause complications if you remove the wrong packages and/or if you use a different recipe in the future.

The only reason to do remove the standard packages that make up some of OpenWrt's core functionality (that admittedly you don't need in this case) is if you are running very low on space and/or RAM that you want to use for other purposes (which would be the exception, not the rule, since you're talking about APs and switches).

Otherwise, I'd recommend simply using the standard images and following the bridged-AP guide. The firewall and routing engines won't take up much in the way of resources since they are not actually being used -- they'll sit essentially idle in the background.

1 Like
5

Thanks everyone, y'all have been very helpful. Combining replies here so I don't flood the thread with replies before I close it. If this is bad, please let me know.

@slh

luci-/ luci-ssl are meta-packages

That solves it, thanks! Installed the sub-components I needed instead of the meta-package and things started making more sense. Clearly I had an XY problem here lol

@dave14305

This is part of luci-mod-status. You can manually remove these files and see if it disappears:

/www/luci-static/resources/view/status/nftables.js
/www/luci-static/resources/view/status/iptables.js

This didn't end up working, but is still very helpful nonetheless. I'm not familiar with LuCI internals yet, but knowing the specific package and where the code is certainly gets me further than I was.

@psherman

I would generally recommend against this. Simply stated, it's an unnecessary step and may cause complications if you remove the wrong packages and/or if you use a different recipe in the future.

We're definitely on the same page here, I figured this is very much in "here be dragons" territory. Was mainly just trying to figure out how big the dragons were gonna be before I charged in to fight them lol

... if you are running very low on space and/or RAM ...

That is part of the reason why I'm doing this. One of these devices is an EdgeSwitch 8XP, which only has 8MB flash. So far, I've managed to reduce the size of the image by about 30% (factory image went from ~6528k to ~4608k) by cutting out unnecessary packages (bulk of the savings was here for sure) and replacing the luci meta-package with the sub-components I actually need (bought me an extra ~500k I didn't think I'd be able to get). The switch's CPU is also extremely slow, so I figure any code I can rip out may make at least a modest improvement (prob wishful thinking)

The main motivation is cosmetic if I'm being totally honest. For example, I want to make the switch "feel" like a basic managed switch rather than a fully-featured router/firewall. Not for production use, just experimenting to learn more about OpenWRT/LuCI internals.

Since reading the replies here, I've got a working (and only somewhat hacky) configuration. Only thing that really feels awkward is a dummy interface needed for netifd to set the bridge up. Not sure how to work around that one yet.

Regardless, you're right, it definitely doesn't feel like one is supposed to rip parts out of LuCI like this. Still, I'm impressed that I can just remove bits of it's brain and see it handle it more or less perfectly. Certainly a robust piece of software that I'm excited to learn more about.

In case anyone stumbles upon this thread while attempting something similar, and doesn't know where to start, here's the packages and uci-defaults script that I used w/ 24.10.1 on an EdgeSwitch 8XP (if you're using something else, you'll need to make tweaks). As said above, here be dragons, make sure you have the tools to go back if you make a mistake.

Packages:

base-files ca-bundle dropbear fstools kmod-gpio-button-hotplug libc libgcc libustream-mbedtls logd mtd netifd odhcp6c opkg procd-ujail swconfig uboot-envtools uci uclient-fetch urandom-seed urngd kmod-usb2 kmod-usb-ohci kmod-dsa-b53-mdio luci-proto-ipv6 luci-app-opkg luci-mod-admin-full luci-theme-bootstrap rpcd-mod-rrdns uhttpd uhttpd-mod-ubus

uci-defaults:

#!/usr/bin/env sh

# Remove most of the default network configuration
while uci -q delete firewall.@defaults[0]; do :; done
while uci -q delete firewall.@zone[0]; do :; done
while uci -q delete firewall.@forwarding[0]; do :; done
while uci -q delete firewall.@rule[0]; do :; done
while uci -q delete network.@device[0]; do :; done

uci delete network.lan
uci delete network.wan
uci delete network.wan6

# Configure management port
uci set network.mgmt=interface
uci set network.mgmt.proto='static'
uci set network.mgmt.device='eth1'
uci add_list network.mgmt.ipaddr='192.168.1.20/24'

# Configure dummy interface so netifd creates and configures the bridge (TODO: Find a way to make netifd set up a device that isn't associated with an interface)
uci set network.switch=interface
uci set network.switch.proto='none'
uci set network.switch.device='br-net'

# Create bridge
uci add network device
uci set network.@device[0].type='bridge'
uci set network.@device[0].name='br-net'
uci set network.@device[0].bridge_empty='1'
uci set network.@device[0].stp='1'
uci set network.@device[0].ipv6='0'

# Enable bridge VLAN filtering
uci add network bridge-vlan
uci set network.@bridge-vlan[0].device='br-net'
uci set network.@bridge-vlan[0].vlan='1'

# Configure ports
for port in lan1 lan2 lan3 lan4 lan5 lan6 lan7 lan8; do
# Add port to bridge
uci add_list network.@device[0].ports="$port"

# Add VLAN 1 to port
uci add_list network.@bridge-vlan[0].ports="$port:u*"

# Disable SLAAC
uci add network device
uci set network.@device[-1].name="$port"
uci set network.@device[-1].ipv6='0'
done

# Save changes
uci commit

# Restart networking and LuCI so the changes take effect
/etc/init.d/network restart
/etc/init.d/uhttpd restart
1 Like
6

Understandable in the situation of an 8MB device. That said, 8MB still works for a basic install, but you'll be armed with this knowledge when the next major release drops support for 8MB devices (however, you'll also need to gain the experience of building images yourself as it will probably no longer be available on the regular image builder).

The CPU does not impact the switching of the device... all switching operations are handled by a hardware switch chip, not the main CPU. Therefore, the benefit here would only be to speed up the UI when you're accessing it.

But the space considerations are real... another useful resource in that context (in case you haven't seen it):

1 Like
7

this should not last through a reboot or removal of the luci-index-cache file, if you used apk to properly remove it. If not .. this should be fixed to allow such configurations ..would not be much work

1 Like
8

The CPU does not impact the switching of the device

I knew this was the case here and from my testing the switching performance with this hardware is excellent on OpenWRT, but yes, the main issue I had was that the UI is painfully slow and I'm too impatient for my own good. Also not sure if layer 3 work could be offloaded to hardware, so that was another consideration.

another useful resource in that context (in case you haven't seen it)

I have not seen this yet, but I'll be sure to dig through it. Extroot looks like a very promising future experiment!

Thanks again!

9

Layer 3 would be achieved in the CPU... so obviously that would be terrible. And you'd want the firewall for that anyway (at least in most scenarios), so a double-whammy.

1 Like
10

You're right, just tried rebooting and that did it, no more ghost menus. Earlier I attempted to remove the luci index cache and restart uhttpd, and despite both steps seemingly succeeding, the ghosts were still there for some reason. I likely just screwed up somehow. Good catch!

11

removing cache is much quicker and can be done from a script or cl..

rm /tmp/luci-indexcache.*.json
1 Like
12

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.