Beim neustart: dhcpd check -> failed

P

PaulAtreides

Well-Known Member
Wenn ich OpenBSD neu starte, wird die Konfiguration als fehlerhaft angezeigt. Wenn ich "/etc/rc.d/dhcpd start" direkt aufrufe, funktioniert alles. Wo könnte ich den Fehler finden?
 
Du tust dir einen Gefallen, wenn du mehr Informationen lieferst. Wenn wir "die Konfiguration" sehen könnten, wäre das schonmal ein guter Anfang. Logfiles wären auch hilfreich (die findest du in /var/log). Wie startest du dhcpd beim Boot? Was sind die Einträge in /etc/rc.conf*?
 
/etc/rc.conf.local
dhcpd_flags=ix0 vlan200 vlan61

In /var/log/daemon oder /var/log/messages gibt es leider keinen Hinweis auf einen Fehler.

/usr/sbin/dhcpd -d läuft ohne Probleme und gibt keine Fehlermeldungen aus.
Ich vermute, es liegt eher am rc.d Skript. Das Problem trat erst nach einem Systemupdate auf.
 
PaulAtreides schrieb:
/etc/rc.conf.local
dhcpd_flags=ix0 vlan200 vlan61

In /var/log/daemon oder /var/log/messages gibt es leider keinen Hinweis auf einen Fehler.

/usr/sbin/dhcpd -d läuft ohne Probleme und gibt keine Fehlermeldungen aus.
Ich vermute, es liegt eher am rc.d Skript. Das Problem trat erst nach einem Systemupdate auf.
Zum Vergrößern anklicken....

Es fehlen wie so oft alle Informationen:

-> Welche OpenBSD-Version? Welche hattest du vorher, welche jetzt?
-> Ein paar Infos über die Hardware, grobe idee was du da genau machst.
-> Wie konfigurierst du die Netzwerk-Interfaces
-> Wie startest du den Daemon genau?
-> Hast du noch was in ner /etc/rc.local?
-> Geht es wenn du die flags rausnimmst?
-> Und natürlich die von @Columbo0815 erwähnte /etc/dhcpd.conf


Meine Idee: Machst du villeicht nach dem start der Daemons irgendetwas was z.B. erst das Interface hoch bringt das du da verwendet?
 
Fehlertext
/etc/rc.d/dhcpd check
dhcpd(failed)

System:
OpenBSD 7.4 GENERIC.MP#3 amd64
Vorher war OpenBSD 7.3

Anwendung:
VDSL Router und Firewall

rc.conf.local
dhcpd_flags=ix0 vlan200 vlan61
ftpproxy_flags=-r
pf=YES
pflogd_flags=
pkg_scripts=miniupnpd
sndiod_flags="NO"
unbound_flags=

Starten ohne Flags
Kein Unterschied. Startet nicht beim Reboot

dhcpd -n
Keine Ausgabe

dhcpd.conf

Code: 
option ntp-servers 192.168.176.2;
option domain-name "DOMAIN";
option domain-name-servers 192.168.176.2;

subnet 192.168.176.0 netmask 255.255.255.0 {
        option routers 192.168.176.8;
        range 192.168.176.20 192.168.176.120;

}

subnet 10.0.60.0 netmask 255.255.255.0 {
        option routers 10.0.60.1;
        range 10.0.60.20 10.0.60.50;

        # HP Farblaser Drucker
        host HPM252dw {
                hardware ethernet 34:68:95:5a:eb:b0;
                fixed-address 10.0.60.14;
        }

}

subnet 10.0.61.0 netmask 255.255.255.0 {
        option routers 10.0.61.1;
        option domain-name-servers 8.8.8.8;
        option ntp-servers de.pool.ntp.org;
        range 10.0.61.20 10.0.61.50;

}

subnet 10.0.200.0 netmask 255.255.255.0 {
        option routers 10.0.200.1;
        range 10.0.200.100 10.0.200.120;

        host telefon10 {
                hardware ethernet 00:0b:82:66:2e:33;
                fixed-address 10.0.200.10;
        }

        host telefon11 {
                hardware ethernet 00:0b:82:67:26:fb;
                fixed-address 10.0.200.11;
        }

        host telefon13 {
                hardware ethernet 00:0b:82:67:26:fd;
                fixed-address 10.0.200.13;
        }

        host telefon14 {
                hardware ethernet 00:0b:82:67:27:30;
                fixed-address 10.0.200.14;
        }

        host telefon15 {
                hardware ethernet 00:0b:82:67:26:fa;
                fixed-address 10.0.200.15;
        }

        host telefon17 {
                hardware ethernet 00:0b:82:6f:20:26;
                fixed-address 10.0.200.17;
        }

        host telefon18 {
                hardware ethernet 00:0b:82:67:26:fc;
                fixed-address 10.0.200.18;
        }

        host telefon19 {
                hardware ethernet 00:0b:82:d1:eb:f4;
                fixed-address 10.0.200.19;
        }

}

subnet 10.0.20.0 netmask 255.255.255.0 {
        option routers 10.0.20.1;
        range 10.0.20.20 10.0.20.50;


        host TTP345 {
                hardware ethernet 00:1B:82:10:52:39;
                fixed-address 10.0.20.3;
        }


        host Samsung {
                hardware ethernet 00:15:99:C7:4E:FC;


}

subnet 10.0.30.0 netmask 255.255.255.0 {
        option routers 10.0.30.1;
        range 10.0.30.30 10.0.30.50;

        host arbeitsplatz4 {
                hardware ethernet 78:45:C4:3A:4A:B3;
                fixed-address 10.0.30.22;
        }

        host arbeitsplatz3 {
                hardware ethernet 78:45:c4:3a:49:a0;
                fixed-address 10.0.30.20;
        }

        host arbeitsplatz2 {
                hardware ethernet 78:45:c4:3a:9d:7e;
                fixed-address 10.0.30.21;
        }

        host arbeitsplatz4 {
                hardware ethernet f0:4d:a2:fe:78:67;
                fixed-address 10.0.30.23;
        }
}

subnet 10.0.50.0 netmask 255.255.255.0 {
        option routers 10.0.50.1;
        range 10.0.50.30 10.0.50.50;

        host arbeitsplatz5 {
                hardware ethernet 6c:4b:90:6b:9d:b4;
                fixed-address 10.0.50.20;
        }

        host GX420d {
                hardware ethernet 00:07:4d:aa:ca:3e;
                fixed-address 10.0.50.21;
        }


}

subnet 10.0.70.0 netmask 255.255.255.0 {
        option routers 10.0.70.1;
        range 10.0.70.30 10.0.70.50;
}
 
spontan fällt mir auf: beim Host "Samsung" fehlt eine schließende curly brace "}", das Subnet 10.0.20.0 wird nicht abgeschlossen - ggf ist das der Grund, warums nicht funktioniert?
 
turrican schrieb:
spontan fällt mir auf: beim Host "Samsung" fehlt eine schließende curly brace "}", das Subnet 10.0.20.0 wird nicht abgeschlossen - ggf ist das der Grund, warums nicht funktioniert?
Zum Vergrößern anklicken....
War ein Fehler beim Kopieren. Die Klammer ist da.
morromett schrieb:
Wie sind sofort nach dem booten und vor dem "rcctl restart dhcpd" (oder gleichwertig), die Ausgaben von:
Code: 
rcctl check dhcpd
dmesg -s | grep -iE 'dhcpd|fail'   # als root
dmesg -s | tail -n 20
?
Zum Vergrößern anklicken....

Code: 
rcctl check dhcpd
dhcpd(failed)

Code: 
dmesg -s | grep -iE 'dhcpd|fail'
starting network daemons: sshd dhcpd(failed) smtpd ftpproxy.

Code: 
dmesg -s | tail -n 20
add net 10.0.50.0/24: gateway 192.168.176.8
add net 10.0.60.0/24: gateway 192.168.176.8
add net 10.0.61.0/24: gateway 192.168.176.8
add net 10.0.70.0/24: gateway 192.168.176.8
add net 10.0.200.0/24: gateway 10.0.200.1
add net 10.0.61.0/24: gateway 10.0.61.1: File exists
add net default: gateway 0.0.0.1
reordering: ld.so libc libcrypto sshd.
starting early daemons: syslogd pflogd unbound ntpd.
starting RPC daemons:.
savecore: no core dump
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd dhcpd(failed) smtpd ftpproxy.
starting package daemons: miniupnpd.
starting local daemons: cron.
Thu Jun 27 16:11:59 CEST 2024
 
Code: 
subnet 10.0.20.0 netmask 255.255.255.0 {
        option routers 10.0.20.1;
        range 10.0.20.20 10.0.20.50;

        host TTP345 {
                hardware ethernet 00:1B:82:10:52:39;
                fixed-address 10.0.20.3;
        }
        host Samsung {
                hardware ethernet 00:15:99:C7:4E:FC;
                fixed-address 10.0.20.11;
       }
}
 
PaulAtreides schrieb:
Code: 
        host Samsung {
                hardware ethernet 00:15:99:C7:4E:FC;
                fixed-address 10.0.20.11;
       }
Zum Vergrößern anklicken....
OK, dann wird es evtl. an einer Abhängigkeit, die beim booten noch nicht vorhanden ist, liegen. Denn manuelles Starten nach dem booten funktioniert ja.
Ich hatte auch so ein ähnliches Problem, mit dem x11vnc. Jetzt starte ich den via crontab, 3 Minuten (verzögert) nach dem booten.
 
Der dhcpd hat glaub ich wenig abhängigkeiten, aber es könnte relevant sein das die Interfaces schon da sind.
 
CommanderZed schrieb:
... das die Interfaces schon da sind.
Zum Vergrößern anklicken....
Ja, aber in OpenBSD gibt es so etwas nicht:
Code: 
[Unit]
Requires=sys-subsystem-net-devices-eth0.device
After=sys-subsystem-net-devices-eth0.device
Requires=sys-subsystem-net-devices-wlan0.device
After=sys-subsystem-net-devices-wlan0.device
...
[Service]
ExecStartPre=/usr/bin/sleep 5
ExecStartPre=/usr/sbin/rfkill unblock wlan
...
;-)
 
morromett schrieb:
Muss es ja auch nicht bzw. würde so auch nicht benutzt werden. Es geht nur um Möglichkeiten. Der (gleichwertige) Workaround in OpenBSD, ist auch aufwendig und nicht schön.
Zum Vergrößern anklicken....

Schon klar war ja nicht so ernst gemeint :P nur damit nich gleich wieder die systemd hater kommen "iihhh in systemd Service files braucht es sleep damit es funktioniert" ;)
 
ist eins der vlans auf einem parent interface, das halt gelinde zeit braucht? man koennte dann dhcpd auch in dessem hostname.if nochmal neu starten (! rcctl restart dhcpd)
 
Klärt aber alles nicht die Frage, was sich denn im Bootprozess nun geändert hat. Neugierig bin ich das schon ...
 
Gar nicht mal gesagt, dass sich beim Bootprozess was geändert hat.
Kann durchaus sein, dass die aktuelle Version vom Dämon aus irgendwelchen Gründen einfach länger zum starten braucht und eben nach der vom rc-Prozess (oder wie immer der heißt) vorgegebenen Zeit abgewürgt wird, weil er noch nicht reagiert. Gabs vor paar Jahren mal bei Samba.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben