DHCP stopped working

Software SW bugs discussion
21

Can you run this experiment:

Stop unbound
Start dnsmasq
Run the netstat command again

I wonder if dnsmasq always tries to bind to port 53 and then releases it: if unbound grabs it first, then dnsmasq is out of luck.

22

Thank you, but it seems nothing has changed in netstat output.
root@turris:~# /etc/init.d/unbound stop
root@turris:~# /etc/init.d/dnsmasq start
root@turris:~# netstat -nap | grep LISTEN | grep 53
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 13652/unbound
tcp 0 0 127.0.0.1:8953 0.0.0.0:* LISTEN 13652/unbound

23

Unbound did not stop. Can you kill it?

24

unbound is controlled by /etc/init.d/resolver

25

root@turris:~# kill 13652
root@turris:~# /etc/init.d/dnsmasq start
root@turris:~# netstat -nap | grep LISTEN | grep 53
There is no output from netstat command.

26

netstat -nap | grep LISTEN | grep dnsmasq

27

netstat -nap | grep LISTEN | grep dnsmasq
Also has no output.

28

Now start resolver and see if both of them are running

29

root@turris:~# /etc/init.d/resolver start
Check generated config /var/etc/unbound/unbound.conf:
unbound-checkconf: no errors in /var/etc/unbound/unbound.conf
Called /etc/init.d/unbound start
set dhcp script
uci: Entry not found
Called /etc/resolver/dhcp_host_domain_ng.py
root@turris:~# netstat -nap | grep LISTEN | grep dnsmasq
root@turris:~# netstat -nap | grep LISTEN | grep unbound
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 14260/unbound
tcp 0 0 127.0.0.1:8953 0.0.0.0:* LISTEN 14260/unbound

30

netstat -nap | grep LISTEN | egrep “67|68”

31

Oh, I missed this part: you cannot start it this way because it is using some default config and not the config from /etc/config/dhcp. We were chasing the the wrong issue.

Pls, compare the config file with the copy under /rom/ line by line. Also, enable detailed debug logs in dnsmasq (I think it can be done via LuCI).

32

when dnsmasq fails what is the output of uci show dhcp | grep port ?

33

Doubt that reveals of why dnsmasq is forced on port 53 in spite of the config. Perhaps strace might show the underlying cause which I think is some script going wrong at some point.

What this case seems to be different from the other posters is that unbound is utilised instead of kresd, if that is any clue about the script code governing each resolver.

34

It is not: if you start dnsmasq from command line with no config file, then it is using a default config with port 53. See DHCP stopped working - #31 by ftmx - SW bugs discussion - Turris forum.

1 Like
35

Are you on TOS3.x? Does it show something like /tmp/etc/dnsmasq.conf.cfg0b411c or just /tmp/etc/dnsmasq.conf

36

The output of this command would be helpful to see.

sh -x /etc/init.d/dnsmasq start
37

Sorry for not responding, but this stupid forum does not allow to reply more than 20 time in first day of registration.

I did a complete restart of turris. All in default config. Everything worked great, but today I have followed this article:
https://doc.turris.cz/doc/en/howto/network_boot

Output of sh -x /etc/init.d/dnsmasq start:

root@turris:/# sh -x /etc/init.d/dnsmasq start

  • START=19
  • USE_PROCD=1
  • PROG=/usr/sbin/dnsmasq
  • DNS_SERVERS=
  • DOMAIN=
  • ADD_LOCAL_DOMAIN=1
  • ADD_LOCAL_HOSTNAME=1
  • CONFIGFILE=/var/etc/dnsmasq.conf
  • HOSTFILE=/tmp/hosts/dhcp
  • TRUSTANCHORSFILE=/usr/share/dnsmasq/trust-anchors.conf
  • TIMESTAMPFILE=/etc/dnsmasq.time

But after restarting dnsmasq, this problem has returned. Can you help me please?

38

you could install strace and look in depth at what happens during the start process of dnsmasq, e.g.

strace -o /tmp/dm_dump /etc/init.d/dnsmasq start

download the dump file to a client. It might be a bit overwhelming looking at the contents if it is the first time you are using strace. In theory the dump should contain 53 somewhere which common text editors could find fast with F3 or whatever invokes its search feature. This may give you a hint of why dnsmasq wants port 53 when it should not.

39

Is dnsmasq running and listening?

netstat -nap | grep dnsmasq

Are there any iptables rules that are blocking access?

iptables-save | egrep "67|68"

40

I really dont know what this means:

root@turris:/# iptables-save | egrep “67|68”
:PREROUTING ACCEPT [428567:288756663]
:OUTPUT ACCEPT [62639:6555567]
-A ucollect_fake -d 192.168.0.122/32 -j MARK --set-xmark 0x80000/0xc0000
-A ucollect_fake -d 192.168.1.1/32 -j MARK --set-xmark 0x80000/0xc0000
-A turris -o eth2 -m limit --limit 1/sec -m set --match-set turris_00CE6700_lb_a_4_X dst -j LOG --log-prefix "turris-00CE6700: " --log-level 7
-A turris -i eth2 -m limit --limit 1/sec -m set --match-set turris_00CE6700_lb_a_4_X src -j LOG --log-prefix "turris-00CE6700: " --log-level 7
-A turris -o eth2 -m limit --limit 1/sec -m set --match-set turris_00CE6701_l_a_4_X dst -j LOG --log-prefix "turris-00CE6701: " --log-level 7
-A turris -i eth2 -m limit --limit 1/sec -m set --match-set turris_00CE6701_l_a_4_X src -j LOG --log-prefix "turris-00CE6701: " --log-level 7
-A turris -o eth2 -m set --match-set turris_00CE6700_lb_a_4_X dst -j DROP
-A turris -i eth2 -m set --match-set turris_00CE6700_lb_a_4_X src -j DROP
-A turris-log-incoming -m limit --limit 1/sec -m set --match-set turris_00CE6700_lb_a_4_X src -j LOG --log-prefix "turris-00CE6700: " --log-level 7
-A turris-log-incoming -m limit --limit 1/sec -m set --match-set turris_00CE6701_l_a_4_X src -j LOG --log-prefix "turris-00CE6701: " --log-level 7
-A turris-log-incoming -m set --match-set turris_00CE6700_lb_a_4_X src -j RETURN
-A turris-log-incoming -m set --match-set turris_00CE6701_l_a_4_X src -j RETURN
-A zone_wan_input -p udp -m udp --dport 68 -m comment --comment “!fw3: Allow-DHCP-Renew” -j accept
root@turris:/# netstat -nap | grep dnsmasq
udp 0 0 0.0.0.0:67 0.0.0.0:* 8049/dnsmasq
udp 0 0 0.0.0.0:69 0.0.0.0:* 8049/dnsmasq
udp 0 0 :::69 :::* 8049/dnsmasq
unix 3 [ ] STREAM CONNECTED 83163 8049/dnsmasq

EDIT:
DHCP started working fine while i was away for a few hours. I really dont know what to think.