Dnsmasq vs kresd

Ok, this is probably how I would like it, but I can’t figure out what configuration to set in LuCI to make that happen. Trying to avoid resetting to factory defaults… any ideas, please?

Strangely I see odhcpd is installed and running as well. Any idea why this would be the case? Two DHCP servers?

I thought LuCI’s DHCP interface configured dnsmasq only, so do you know how odhcpd would be configured?

My /etc/config/dhcp is below. I think just replacing it should be fine, except that you may want some thing a bit different, e.g. 192.168.x.y.

config dnsmasq
	option domainneeded '1'
	option boguspriv '1'
	option localise_queries '1'
	option domain 'lan'
	option expandhosts '1'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.auto'
	option localservice '1'
	option port '0'
	option rebind_protection '0'
	option nonwildcard '0'
	option dhcpscript '/etc/resolver/dhcp_host_domain_ng.py'
	option local '/lan/'

config dhcp ‘lan’
option interface ‘lan’
option leasetime ‘12h’
option dhcpv6 ‘server’
option ra ‘server’
option start ‘10’
option limit ‘89’
list dhcp_option ‘6,’
option ra_management ‘1’

config dhcp ‘wan’
option interface ‘wan’
option ignore ‘1’
list dhcp_option ‘6,’

config odhcpd ‘odhcpd’
option maindhcp ‘0’
option leasefile ‘/tmp/hosts/odhcpd’
option leasetrigger ‘/usr/sbin/odhcpd-update’

config dhcp ‘guest_turris’
option interface ‘guest_turris’
option start ‘200’
option limit ‘50’
option leasetime ‘1h’
option ignore ‘1’
list dhcp_option ‘6,’

config domain

config host

You have dnsmasq port set to 53. You should set it to 0 to disable its DNS server.

Thanks for sharing! So it looks like one then has to have a custom dnsmasq option set in the Advanced DHCP menu on the LAN interface? Setting dnsmasq’s port to 0 makes it also stop auto-advertising the router as a DNS server in DHCP responses, so a custom dhcp-option is required.

From a usability perspective this kind of blows. I love the power these routers provide, but I kind of expect the basics to be well handled by the UI without configuration quirks like this.

So am I right in saying it’s either this workaround or forever living with auto-updates re-enabling kresd which then breaks DHCP?

1 Like

Or disabling auto-updates I guess. The best feature of these routers.

Switching DNS resolver is officially unsupported on Turris. Just as OpenWRT doesn’t well support multiple options.

I’m not sure what this means. It is not me who installed or enabled kresd. The auto-updater did so.

Yes, Omnia uses kresd by default. You tried to change that apparently, and that broke things after some updates.

odhcpd is used for DHCP ipv6 but can also be used for DHCP ivp4, like my end. Meaning that I have removed dnsmasq from the router.

1 Like

Omnia used to use dnsmasq by default. An auto-update introduced kresd some time in the past, and that became the new default.

I’m not trying to change the defaults. I’m just trying to make them work without strange quirks. With this new kresd default I have to know:

  1. That its normal for LuCI to need the DNS server port set to 0 to disable dnsmasq’s DNS server and workaround kresd being the new default.
  2. That the LAN interface now needs another configuration workaround (dhcp_option ‘6,192.168.x.y’) to workaround the quirk introduced by (1) that makes dnsmasq stop advertising the router as a DNS server to LAN.
  3. If I or someone else ever changes the router’s LAN IP in LuCI, they have to know to update this configuration workaround in (2), or your LAN clients get served an invalid DNS server IP.

Whoever thought that wedging kresd in as the new default resolver must not care much about the usability of LuCI. Surely LuCI should have been updated appropriately so that the above quirks aren’t necessary?


No, Turris has never used dnsmasq for DNS by default.

My memory disagrees, but if you say so. Either way it doesn’t change the fact that the present situation is a configuration mess. There’s nothing intuitive about the configuration requirements in LuCI to make dnsmasq and kresd work together in the default supported manner.

I had changed the LAN IP just by selecting in Foris. I didn’t need to configure anything else.

Yes, that would be nice to improve, but I suspect it would need basically a rewrite of that luci module.

Thankfully Foris does update the “dhcp_option ‘6,192.168.x.y’” setting itself. So I guess the best we can say is that LuCI is a foot-shooting mess and to just avoid it as best one can. :frowning:

1 Like

Generally, what can be done in Foris should be done there. DNS is the worst part on luci side AFAIK; the other parts should work OK, I think.

Hopefully future updates will fix LuCI’s issues. Thank you for your time and input, vcunat!

1 Like

I must support @Aragon with what he describes in hist summary post.

I am completely new user of Turris - my shiny new Turris MOX just arrived in mailbox on Friday - and I already spent like half a day trying to solve task, which usually took less than 5 minutes on any of my previous routers.
I just wanted my DHCP clients to be able to connect to the internet and resolve local hostnames. Simple thing I never thought about on any previous routers, but on Turris, it doesn’t work out of the box and there are lot of posts dating back to 2014 trying to solve this - sometimes by using horrible solutions.

I didn’t try to change any default setting or configuration of my MOX apart from name of the local domain, which I changed from default “lan”. That’s it, no other changes from default.

I ended with most of my Linux clients having only one line in /etc/resolv.conf, which was “domain DOMAIN_NAME”. No dns server defined there, so these clients were completely without internet. And when I finally found, that the fix is buried in advanced dhcp configuration of the LAN interface.

To be honest, I don’t even know which of the solutions fixed the resolving of the local hostnames, but it is definitely not a “good first experience” I was looking forward to while waiting for MOX…

Looks to me, like the main issue is that there are two configuration interfaces and neither can be used to set everything. When you combine it with non working default settings, it is a bit painful start for anyone new to this platform.

1 Like

I suspect MOX issues might be something completely else, also given that their Turris OS version is still called “alpha”. I’d expect it better not to mix it with Omnia topics unless it’s clear it manifests the same way for both. Your main problem seems that you didn’t get a good DNS resolver address/setting over the DHCP protocol from MOX to clients, which seems unrelated to this thread.

1 Like