Add Dnsmasq Custom Options field in LuCi GUI

For Developers
1

Should we add a new option in Luci > Network > DHCP and DNS where you can configure any valid Dnsmasq command in a custom field?

As it stands now, you always have to edit manually the file in /etc/dnsmasq.conf via SSH.

Having a custom textarea field like this would allow you to change any additional Dnsmasq via the GUI:

We could potentialy also add the same configuration field to be configurable with uci via SSH as well.

The benefit of this approach is that we don't have to manually create commits for each and every new option for Dnsmasq after every update, since they can all be added using this field by default.

Currently, we do have issues where Dnsmasq functions like dns-rr are waiting for a review and approval for a very long time: https://github.com/openwrt/openwrt/pull/14269

Other router firmwares also already have this Dnsmas custom options field implemented for a very long time. For example:

Would you like something like this to be added to OpenWrt GUI as well?

5 Likes
2

This is not a bad idea. Such a field covers edge cases, and avoids waiting for code-change PRs for custom new dnsmasq options to pass non-existent code-reviews. It's actually feasible in that we can use the existing confdir setting in dnsmasq.init. Luci stores the edits in the dhcp config, and also writes it out to a temp config file in the confdir path at every apply, dnsmasq runs with the custom options.

Zero error checking. No GUI helpers. Applies globally to all instances unless one modifies the confdir (which defaults to /tmp/dnsmasq.d).

Set confdir for a specific instance, and the init process makes the new .d folder. But who "gets there first" if we try to write to a config file (directly from luci) that should go in that folder which might not exist yet? Luci tries to write the file first because the uci commands have not filtered down to the init script reload yet. So there may be a situation where one must apply the config twice for it to take effect (if we choose to write to a unique /tmp/dnsmasq.instanceX.d/ folder).

So this will need changes to the init process. Because for people to apply custom config options, who don't have luci, they need to happen in... dnsmasq.init.

But long term, it's a good thing to have, I think.

1 Like
3

I would love to see this, right now I have to do this to add IPv6 ntp servers.

uci add_list dhcp.lan.ntp='fd88::1'
uci commit dhcp
service odhcpd restart
4

Those are great points, thank you so much for the reply and the details.

Having a confdir (or an even a single conf file) designated for this feature would be one way to solve it.

LuCi can write whatever is put in that Dnsmasq Custom field to the config file and restart dnsmasq after.

Regarding users that don't have LuCi installed, they could also simply edit the actual designated conf file directly.

Perhaps no need to make it more complicated by adding it as a value field with uci, as I'm worried that it might cause issues the longer the commands get, and also is less manageable via uci set instead of a simple file edit.

We could have the file saved in /etc/config so that it gets included when doing a backup and across reboots.

5

Tempting. I just wrote about a problem with this.

1 Like
6

Hmm - that looks like an odhcpd dependent setting. But I don't see it documented here: https://openwrt.org/docs/techref/odhcpd

That works to get NTP advertised in IPv6?

7

That's a good catch.

How about in a subfolder inside it, like /etc/config/custom/

Are those affected as well? I use that in my current config and didn't notice the uci issue

8

All in favour :+1:

3 Likes
9

Yes it does.

10

Edit: got it. DHCPv6 (only). So what options are useful? Fill with the system assigned NTP servers, as well as being able to assign some IPv4/6 or FQDN?

@openwrtforever this is now in openwrt/luci.

11

This kind of misses the point. The config contents can be stored in uci, in the dhcp file. At config apply, when dnsmasq initialises, uci loads that info and then writes it out to a custom config file, which is loaded at dnsmasq run-time. Everything is done on the fly.

Doing it your way is possible, but then that file needs adding to /etc/sysupgrade.conf so it gets carried across upgrades.

Anyway, I included it in https://github.com/openwrt/openwrt/pull/14975

So you can replace your dnsmasq.init file.

The option dnsmasq instance option is e.g.

config dnsmasq 'rekt'
	...
	option extraconf 'log-async=20\n\n'
2 Likes
12

Awesome! That's even better.

Everything in the /etc/config folder seems to survive a restore and sysupgrade by default now, even the subfolders inside of it like /etc/config/custom

But having a proper solution like you've mentioned is even better. Thanks for including it in the PR.

13

The firewall config used to (maybe still does) have the extra option, maybe the dnsmasq one should be named the same.

Shouldn't be too hard to modify the dnsmasq init script to parse the list of extra settings and include them in dnsmasq config.

2 Likes
14

Thank you for the reply.

Yes, there is a commit by @systemcrash adding the option and it seems to work pretty good: https://github.com/openwrt/openwrt/pull/14975/commits/c1f7164f74ce8f52955bae12684062b62b8be30d

It's part of this Pull Request that requires 4 more reviews before it would be added to the main: https://github.com/openwrt/openwrt/pull/14975

If you can, please check it out and let us know if it works good or if there are any suggestions to improve it.

I can post a more detailed guide on how to try it out if needed

15

Just FYI, that is a safety measure to ensure no PRs ever get merged from github without a maintainer’s involvement.

1 Like
16

That is a good feature indeed.

However, some PRs also seem to be forgotten for a long time waiting for a review, for example: https://github.com/openwrt/openwrt/pull/14269

1 Like
17

It's terrible, but it's better than nothing. The core-system needs high walls to prevent things breaking. But it seems developers are not fully aware of... revert.

It's terrible because lots of good PRs simply rot - there are not enough eyeball hours to review the PRs, and it requires six, SIX approvals from openwrt members, although approvals help advertise the need of some PRs.

1 Like
18

I've tested the new version of the Dnsmasq Custom Options feature created by @systemcrash and it seems to be working properly.

The new feature adds a new configurable field with uci for dnsmasq called extraconftext that can be used to add any supported option by the current dnsmasq version in OpenWrt. Technically, most of these features are now configurable via uci: https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

If you want try and test the commit, these are the steps:

  1. Make a backup of your current configuration via Luci > System > Backup > Generate archive

  2. Create 2 new folders on your Desktop called dnsmasq-backup and dnsmasq-new (Terminal on macOS is used for this example, but the same can be applied to other platforms)

  3. Save a backup of your current dnsmasq file from OpenWrt by using this command in Terminal:
    scp -O root@192.168.1.1:/etc/init.d/dnsmasq ~/Desktop/dnsmasq-backup/

  4. Download the latest dnsmasq.init file from https://raw.githubusercontent.com/systemcrash/openwrt/dnsmasq_filter_rr_v2/package/network/services/dnsmasq/files/dnsmasq.init and save it to ~/Desktop/dnsmasq-new/dnsmasq

  5. Make the new dnsmasq file executable with this command:
    chmod +x ~/Desktop/dnsmasq-new/dnsmasq

  6. Upload the new dnsmasq file to OpenWrt:
    scp -O ~/Desktop/dnsmasq-new/dnsmasq root@192.168.1.1:/etc/init.d/

  7. Log into OpenWrt using SSH, and use uci to setup a custom configuration:

uci set dhcp.@dnsmasq[0].extraconftext='address=/example.com/0.0.0.0'
uci commit dhcp
  1. Restart the new dnsmasq file to apply the new configuration:
    /etc/init.d/dnsmasq restart

That's it!

You can use any valid dnsmasq option in the extraconftext configuration. In the example above, we used address=/example.com/0.0.0.0

You can also add multiple lines separated by \n. For example, to add

address=/example.com/0.0.0.0
server=1.1.1.1

use these commands in OpenWrt via SSH:

uci set dhcp.@dnsmasq[0].extraconftext='address=/example.com/0.0.0.0\nserver=1.1.1.1''
uci commit dhcp
/etc/init.d/dnsmasq restart

What this does is it will create a new dnsmasq.conf file in /tmp/dnsmasq.cfg01411c.d/extraconfig.conf with the specified options and will read that file with the rest of the dnsmasq configurations on initialization. The folder is created based on the name of your dnsmasq config name.

Please note that as this feature can accept any dnsmasq option, it's up to you to make sure what you add to it doesn't conflict with other configurations.

If you can, try out the new dnsmasq.init file using the guide above, check if it works properly, and review it or add suggestions on its Pull Request: https://github.com/openwrt/openwrt/pull/14975

To revert back to your original dnsmasq file, you can use the backup file from the guide above:
scp -O ~/Desktop/dnsmasq-backup/dnsmasq root@192.168.4.6:/etc/init.d/

If you use a squashfs image for OpenWrt, you can also delete the modified file from the overlay and use the original dnsmasq file from the squashfs image:

cd /overlay/upper/etc/init.d/
rm -rf dnsmasq
mount -o remount /
/etc/init.d/dnsmasq restart
1 Like
19

Why can‘t you just use /etc/dnsmasq.conf for this purpose? It is readily supported and a ui fronted for custom options could just write into that file.

1 Like
20

That's a good question and modifying the /etc/dnsmasq.conf via LuCi was my initial thought.

However, there might be some complications when using that approach: Add Dnsmasq Custom Options field in LuCi GUI - #11 by systemcrash

I think @systemcrash might be able to answer your question in more detail