Grooming /etc/config/

For several days, I have been manipulating LuCi to create and delete interfaces, Vlan, DHCP and DNS servers, firewalling rules, etc.

I observe that LuCI does not clean up the configuration files well. For example, in /etc/config/dhcp or /etc/config/network, incomplete fragments of old configurations are stored which no longer appear in LuCI. My understanding is that these incomplete fragments are simply ignored when reading the configuration files.

What is the recommended method of cleaning up the configuration files of this slag, once things have stabilised?

1 Like

If you do big complex config setup/changes it is probably most effective to work in uci or write directly in the config files.

Generally I use only luci for viewing and small config changes.

Please provide some examples of such configuration fragments which are not visible in LuCI - this most definitely is a bug.

Which is entirely besides the OP‘s question

For instance, in /etc/config/dhcp, none of the following should exist any more. All these fragments come from previous trial and error.

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv6 'server'
	option ra 'server'
	list dhcp_option '6,192.168.1.1'


config dhcp 'wan'
	option interface 'wan'
	option ignore '1'


config dhcp '2411'
	option interface '2411'
	option leasetime '1w'


config dhcp 'team2411'
	option interface 'team2411'
	option leasetime '1w'
	option start '0'
	option limit '0'


config dhcp 'devices2471bis'
	option leasetime '12h'
	option interface 'devices2471bis'
	option start '1'
	option limit '253'

So these are DHCP server entries from network interfaces that were subsequently deleted?

Thank you. Indeed, LuCI only clears depending entries from /etc/config/network, /etc/config/firewall and /etc/config/wireless on deleting an interface. The dhcp config is not covered. Will add cleanup for it.

Are there any other artifacts not covered? Right now only sections of type alias, route and route6 are removed in the network config if the corresponding interface is deleted, I suppose it needs to be extended to rule and rule6 as well.

1 Like

Correct, except for wan which obviously exists still. Nevertheless, its option ignore '1' seems questionable to me.

Do I understand from your initial responses that there is no other recommended method than to delete these irrelevant lines by hand?

This is actually correct, it specifically tells dnsmasq to ignore any inbound DHCP and DNS requests on that interface. It is also part of the shipped default configuration:

At the moment, yes. Will implement a fix to clear up stale DHCP pools as well when deleting an interface from LuCI. Until then you either need to delete those pools before deleting the corresponding interface or remove them manually via command line.

3 Likes

Thank you for this clarification.

Oh, really?

I had created a wildcard rule on the firewall, which allowed port 53 from any zone, and the DNS responded when queried from the WAN (that WAN is actually an RFC1918 LAN), despite the presence of option ignore '1'. I had to give up the wildcard rule, in order to be able to gag the DNS on the WAN interface.

My previous statement was not fully correct, afair option ignore only applies to DHCP requests, not to DNS ones.

Thank you.

1 Like

Do we have a tool to test the validity of a configuration file, after manually cleaning it up?

The manual cleanup of the /etc/config/dhcp file went smoothly. However, I managed to lose all connectivity after editing the /etc/config/network file. As soon as I rebooted the router, it seemed to be unable to recreate its VLANS and subnet IP.

On this particular router (it's a Turris Omnia), it was possible to rollback to a previous system image, which minimised the implications of the mistake. However, it would be better to check the validity of a manually cleaned configuration file, to avoid such incidents completely.

https://openwrt.org/docs/guide-user/base-system/uci#corrupted_configs
However, this only applies to syntax errors, not logical errors.

1 Like

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