After September 15 update, DHCP does not work at all

Software SW bugs discussion
1

I had the update for my Turris Omnia last night and now my DHCP does not work at all. All clients hang on “Getting IP address”.

I see this in my syslog, maybe this has something to do with it:

2017-09-15T07:37:10+02:00 crit dnsmasq[2775]: failed to create listening socket for port 53: Address in use
2017-09-15T07:37:10+02:00 crit dnsmasq[2775]: FAILED to start up

Port 53 is already used by a process called “kresd”.

I have to stress that I am not doing any advanced stuff with my Turris. I just use it as an access point for my home. I didn’t change any scripts/config files manually, I just use the web config interface. In the web interface, everything looks like it’s correctly configured but there are no leases displayed. If you tell me to “disable kresd”, I have no idea how to do it.

Whet I did a rollback to last snapshot using schnapps, everything worked OK. When I performed the update, DHCP is not working again…

2

What is the content of /etc/config/dhcp file?
And mainly the option port from config dnsmasq section.

3

Solved it myself:

In the file /etc/config/resolver, I changed this line:

option prefered_resolver 'kresd'

To this:

option prefered_resolver 'dnsmasq'

Now everything is OK.

FYI, I never heard about this file or kresd before.

4

The content of /etc/congif/dhcp is currently as follows (but I already fixed the problem, see above):

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

config dhcp 'lan'
	option interface 'lan'
	option start '130'
	option limit '100'
	option leasetime '12h'
	option ignore '0'
	list dhcp_option '6,192.168.69.99'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'
	list dhcp_option '6,10.200.85.20'

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

config host
	option name 'sklad'
	option mac '00:22:b0:ea:b6:f4'
	option ip '192.168.69.97'

config host
	option name 'frantisek'
	option mac 'fc:aa:14:0e:80:4f'
	option ip '192.168.69.1'

config domain
	option name 'gate'
	option ip '192.168.69.99'

config host
	option name 'tiskarna'
	option mac '7c:e9:d3:b0:05:c0'
	option ip '192.168.69.50'

config host
	option ip '192.168.69.2'
	option name 'pi'
	option mac 'b8:27:eb:e2:c1:37'

config domain
	option name 'sklad'
	option ip '192.168.69.97'

config dhcp 'guest_turris'
	option interface 'guest_turris'
	option start '200'
	option limit '50'
	option leasetime '1h'
	option ignore '0'
	list dhcp_option '6,10.111.222.1'
5

kresd (or knot-dns-resolver) is the default dns resolver on turris omnia and dnsmasq resolver is disabled by default. At some point int time you stoped knot-dns-resolver and enabled resolving via dnsmasq and now both of them started at the same time and knot was faster to bind to the port and thus dnsmasq hasn’t started. There should have been option port '0' in dnsmasq section.

6

I vaguely remember manually entering “Port 53” value into web configuration because I was instructed to do so in the Turris forums. Without without doing this, my local hostnames (e.g. sklad.fx, gate.fx, frantisek.fx) didn’t work at all.

But I certainly didn’t enable/disable any resolver. I didn’t know Turris uses multiple resolvers until today.

7

I think, that that is not the best solution, because dnsmasq is not able to check DNSSEC, but with this should help somebody else with deeper knowledge.

DNS “part” of dnsmasq should be disabled by default… not sure why it tries to bind to port 53.

Not sure, if that’s the best solution, but if you want to check it more, I would try following steps:

  • Configure option prefered_resolver back to 'kresd'.
  • Add option port '0' (or option port '53535') to the /etc/config/dhcp file into config dnsmasq section.
  • Restart resolver (an maybe dnsmasq):

/etc/init.d/resolver restart
/etc/init.d/dnsmasq restart


UPDATE: there is better explanation from @miska above...
8

See my post from 10:46. Will my local domain names keep working after doing what you suggest?

9

With 3.8 it should be possible to propagate client names into local DNS (configuration option in foris -> DNS), so basically yes.

I have it configured slightly more complexly - dnsmasq is listening on port 53535 and kresd asks for names in my domain on that port. (The solution was described somewhere on this forum, but I’m not sure if it is still current - there might be better solution now.)

10

With 3.8 it should be possible to propagate client names into local DNS (configuration option in foris → DNS), so basically yes.

But that’s not what I want. I need for a client with MAC address xx:xx:xx:xx:xx:xx to always have specified hostname, regardless of what the client says its name is.

11

Some people still use it: 3.8 - forwarded DNS resolution not working - even though dig against ISP's DNS servers works fine

12

Same problem on Turris 1.1.

In ‘/var/log/messages’:

2017-09-16T13:49:18+02:00 crit dnsmasq[7746]: illegal repeated keyword at line 10 of /var/etc/dnsmasq.conf
2017-09-16T13:49:18+02:00 crit dnsmasq[7746]: FAILED to start up

At line 10 of /var/etc/dnsmasq.conf:

port=0

There is also new line in /etc/config/dhcp:

option dhcpscript ‘/etc/resolver/dhcp_host_domain_ng.py’