DHCP (dnsmasq) náhodně vypadává (přestává poslouchat na portu 67)

Ahoj, u původního Turrisu se objevil nepříjemný problém. Jednou za čas (pár dní), náhodně, přestane odpovídat DHCP. Když si pak nastavím statickou IP, vše ostatní (DNS, přístup na router a ven) funguje normálně. Příkaz /etc/init.d/dnsmasq restart DHCP opět nahodí.

V logu jsem nic nenašel. Zkoušel jsem toto:

root@turris-ch:~# logread -e dnsmasq ; pgrep -fa dnsmasq; netstat -lnp | grep dnsmasq

3407 /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c -k -x /var/run/dnsmasq/dnsmasq.cfg01411c.pid
3415 /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c -k -x /var/run/dnsmasq/dnsmasq.cfg01411c.pid

Po restartu služby dnsmasq:

root@turris-ch:~# logread -e dnsmasq ; pgrep -fa dnsmasq; netstat -lnp | grep dnsmasq

Sep  8 20:00:39 turris-ch dnsmasq[3407]: started, version 2.80 DNS disabled
Sep  9 08:09:54 turris-ch dnsmasq[3407]: overflow: 2 log entries lost
Sep  9 06:09:54 turris-ch dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
Sep  9 06:09:54 turris-ch dnsmasq: Allowing 127.0.0.0/8 responses
Sep  9 08:09:58 turris-ch dnsmasq[31026]: started, version 2.80 DNS disabled
Sep  9 08:09:58 turris-ch dnsmasq[31026]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth nettlehash DNSSEC no-ID loop-detect inotify dumpfile
Sep  9 08:09:58 turris-ch dnsmasq-dhcp[31026]: DHCP, IP range 192.168.2.100 -- 192.168.2.249, lease time 12h
Sep  9 08:09:58 turris-ch dnsmasq-dhcp[31026]: read /etc/ethers - 0 addresses
31026 /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c -k -x /var/run/dnsmasq/dnsmasq.cfg01411c.pid
31028 /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c -k -x /var/run/dnsmasq/dnsmasq.cfg01411c.pid
udp        0      0 0.0.0.0:67              0.0.0.0:*                           31026/dnsmasq

Všiml jsem si, že při výpadku zřejmě přestane dnsmasq poslouchat na portu 67, viz poslední řádek výpisu, který před restartem chybí:

udp        0      0 0.0.0.0:67              0.0.0.0:*                           31026/dnsmasq

Konfiguraci /etc/config/dhcp jsem porovnal s konfigurací na svém druhém Turrisu, kde k výpadkům nedochází, a liší se pouze rozsahy a nastavením statických adres. Relevantní část:

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.auto'
	option port '0'
	option localservice '1'

V logu jsem žádné chyby nezaznamenal, ale nevím, jestli by se dnsmasq nedalo nějak zvýšit verbosity.

Nesetkal se někdo s něčím podobným nebo nedokázal by poradit, v čem by mohl být problém, případně jaké další kroky podniknout pro další diagnostiku?

Jako nouzové řešení bych si asi udělal skript, který by pravidelně kontroloval, zda dnsmasq poslouchá, a pokud ne, restartoval by jej. Ale neměl bych z toho dobrý pocit.

Pro úplnost:

Device: Turris
Turris OS version: 5.4.2
Turris OS branch: HBS
Verze kernelu: 4.14.291

Bohužel příčinu problému jsem nenašel.

Chvíli jsem si myslel, že by DHCP server mohl padat kvůli zmatení požadavky z druhé strany VPN spojení, ale problém přetrvával. Navíc jsem si skoro jistý, že jsem se s ním potýkal už v průběhu svých experimentů s VPN.

Nakonec jsem se rozhodl začít s čistým štítem - udělat factory reset, vše znovu ponastavovat a znovu zprovoznit site-to-site VPN bridge. Nyní už běžím týden bez výpadku DHCP.

P.S.: Ale musím říct, že dostat můj Turris 1.0 s MicroSD a BTRFS do továrního nastavení se ukázalo jako pořádná anabáze. Napřed jsem obnovil snapshot číslo 1 (ostatní staré snapshoty už někam zmizely), kde jsem zjistil, že mám ještě TOS 3. Tak jsem spustil migraci na TOS 5, která se ale nakonec zasekla tak nešťastně, že jsem přišel o spojení s routerem. Takže šroubovák a sériová linka (díky bohu za interní USB konektor) a zjištění, že mi při bootu hlásí “kernel panic”… Vyjmutím MicroSD karty měl router nabootovat postaru, jenže po vyjmutí startovat odmítal zaseklý v nějaké pár vteřin trvající boot smyčce. To byl asi okamžik největšího zmaru a studeného potu. Proč se to dělo, to nevím, možná jsem nechal zapojenou sériovou linku, takže byla část routeru během vyjímání paměti a SD karty pod napětím? V každém případě po cca půl hodině, co byl vypnutý a odpojený, naběhl. Hurá. Takže jsem SD kartu promazal, znovu zapojil a znovu provedl migraci na BTRFS. Mezitím jsem se dočetl, že lze stáhnout nejnovější balík s čistým systémem a ten nahrát coby snapshot. Proč mi tohle nikdo neřekl dřív…

1 Like

Že Vy jste se nezeptal? Jinak gratuluji k vyřešení problému, byť kvůli němu musel být celý systém reinstalován.

To je citace Rimmera z Červeného trpaslíka, ale tušil jsem, že se asi moc nechytne…

2 Likes

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.