Dnsmasq vs kresd

Software SW bugs discussion
1

Hello. I constantly have issues with dnsmasq and kresd clashing over port 53. In most cases kresd starts up first and binds to port 53. Then dnsmasq fails to start due to port 53 being already bound, and without dnsmasq the LAN’s DHCP service doesn’t exist.

I have in the past disabled/removed kresd, only for it to re-appear after a software update and cause the same problems again. I’ve also tried setting the DNS listen port to 0 in LuCI, but then dnsmasq doesn’t advertise a DNS server to DHCP clients. This whole mess seems like a major oversight in the OS design.

How are Omnia users supposed to configure their routers so that this issue doesn’t keep happening? Personally I’ve spent hours debugging and fixing this issue again and again.

1 Like
2

DNS (port 53) and DHCP (ports 67/68) are different services and for each only one server should be present, which is in the vanilla setup. There is no need for dnsmasq to provide DNS (port 53) when it is already done by kresd or vice versa.

kresd can be either uninstalled or disabled if dnsmasq is the preference for DNS.

3

I suggest you reset this to factory settings. No clash happens by default :wink:

4

dnsmasq is both a DNS and DHCP server. What would function as the DHCP server in the absence of dnsmasq? It sounds like dnsmasq has become a non-standard daemon over time, and I can only recall it being the one and only DNS+DHCP server on Turris Omnia.

5

Neither of us suggest uninstalling dnsmasq. The default uses it for DHCPv4 on LAN + kresd for DNS.

6

An alternative is odhcpd which is dhcp solely.

7

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?

8

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?

9

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,192.168.8.1’

option ra_management ‘1’


config dhcp ‘wan’

option interface ‘wan’

option ignore ‘1’

list dhcp_option ‘6,192.168.1.2’


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,10.111.222.1’


config domain


config host
1 Like
10

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

1 Like
11

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?

2 Likes
12

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

13

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

14

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

15

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

16

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
17

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?

3 Likes
18

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

19

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.

20

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.