Keine Antwort vom DHCP des dnsmasq

[Schultze]

Hallo Gruppe,

ich habe am Montag das aktuelle stable installiert und bekomme seit dem den ersten Dienst, den ich aktivieren wollte nicht zum laufen.
Ich möchte, damit die interne Namensauflösung funktioniert den dnsmasq als DHCP und DNS nutzen. Das hat unter squeeze auch bis Montag problemlos funktioniert.
Jetzt unter jessie bekomme ich den DHCP nicht ans laufen, der DNS funktioniert.

Ich teste mittels dhcping und bekomme konsequent die Antwort:
# dhcping -s 192.168.42.3
no answer

Probiere ich das Gleiche mit dem Router (der derzeit den DHCP spielt) gibt es diese Antwort:
# dhcping -s 192.168.42.1
Got answer from: 192.168.42.1

Bei jeder Anfrage mittels dhcping kommt hier eine Zeile hinzu:
# systemctl status dnsmasq.service|grep dhcp
Dec 19 21:31:09 dalmore dnsmasq-dhcp[2213]: DHCP, IP range 192.168.42.111 -- 192.168.42.222, lease time 12h
Dec 19 21:43:50 dalmore dnsmasq-dhcp[2213]: 510083577 available DHCP range: 192.168.42.111 -- 192.168.42.222
Dec 19 21:58:50 dalmore dnsmasq-dhcp[2213]: 2054150484 available DHCP range: 192.168.42.111 -- 192.168.42.222
Dec 19 22:10:41 dalmore dnsmasq-dhcp[2213]: 1036547414 available DHCP range: 192.168.42.111 -- 192.168.42.222
Dec 19 22:11:29 dalmore dnsmasq-dhcp[2213]: 1858630998 available DHCP range: 192.168.42.111 -- 192.168.42.222

Meine .conf sieht so aus:
# Configuration file for dnsmasq.
#
no-dhcp-interface=eth1
dhcp-range=192.168.42.111,192.168.42.222,255.255.255.0,12h
dhcp-option=3,192.168.42.1

Im Netz habe ich bisher keine hilfreichen Tipps gefunden.
Hat hier jemand eine Idee, woran das liegen kann? Ich brauche eure Hilfe.

Danke,
Schultze

[Schultze]

Hallo Gruppe,

....
Ich teste mittels dhcping und bekomme konsequent die Antwort:
# dhcping -s 192.168.42.3
no answer

Ergänzung:
netstat meldet folgendes

# netstat -panel | grep dnsmasq
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 0 12612 2213/dnsmasq
tcp6 0 0 :::53 :::* LISTEN 0 12614 2213/dnsmasq
udp 0 0 0.0.0.0:53 0.0.0.0:* 0 12611 2213/dnsmasq
udp 0 0 0.0.0.0:67 0.0.0.0:* 0 12608 2213/dnsmasq
udp6 0 0 :::53 :::* 0 12613 2213/dnsmasq
unix 2 [ ] DGRAM 12622 2213/dnsmasq

Sieht für mich so aus, als ob dnsmasq auf UDP:67 lauscht. Oder sehe ich das falsch?

Danke,
Schultze

[MSfree]

no-dhcp-interface=eth1
dhcp-range=192.168.42.111,192.168.42.222,255.255.255.0,12h
dhcp-option=3,192.168.42.1

Ist eth1 die Schnittstelle, über die du die Clients mit DHCP versorgen willst?

no-dhcp-interface bedeutet nämlich, daß nur DNS aber kein DHCP über die Schnittstelle serviert wird.
Da sollte nur interface stehen.

Sieht für mich so aus, als ob dnsmasq auf UDP:67 lauscht. Oder sehe ich das falsch?

Genau genommen sind es die Ports 67 und 68.

[Schultze]

Ist eth1 die Schnittstelle, über die du die Clients mit DHCP versorgen willst?

Nein, eth1 ist derzeit nicht in Benutzung.

Genau genommen sind es die Ports 67 und 68.

Von Port 68 sehe ich da aber nichts. Kann die fehlende Antwort damit zusammenhängen?

Schultze

[MSfree]

Nein, eth1 ist derzeit nicht in Benutzung.

Welche ist denn dann in Bnutzung.
In deiner Konfiguration fehlt nämlich ein Eintrag der Art
interface=ethX
Die Zeile teilt dnsmasq mit, auf welcher Schnittstelle DNS- und DHCP-Anfragen serviert werden.

Von Port 68 sehe ich da aber nichts. Kann die fehlende Antwort damit zusammenhängen?

Ich vermute, es liegt daran, daß du die Netzwerkschnittstelle nicht spezifiziert hast (s.o.).

[Schultze]

Welche ist denn dann in Bnutzung.

eth0

In deiner Konfiguration fehlt nämlich ein Eintrag der Art interface=ethX
Die Zeile teilt dnsmasq mit, auf welcher Schnittstelle DNS- und DHCP-Anfragen serviert werden.

Laut der Kommentare in der .conf ist das aber nicht notwendig. Es werden alle Interfaces bedient, welche nicht ausgeschlossen werden. DNS funktioniert ja auch.

(Port 68) Ich vermute, es liegt daran, daß du die Netzwerkschnittstelle nicht spezifiziert hast (s.o.).

Habe ich eben getestet, keine Änderung.

Schultze

[Schultze]

Genau genommen sind es die Ports 67 und 68.

Ich habe gerade mal nachgelesen, Port 68 ist für den DHCP-Client. Den habe ich ja nicht laufen, es soll ja mein DHCP-Server sein.

Schultze

[habakug]

Hallo!

Probiere ich das Gleiche mit dem Router (der derzeit den DHCP spielt) gibt es diese Antwort:
# dhcping -s 192.168.42.1
Got answer from: 192.168.42.1

Nur um es mal zu erwähnen: Der DHCP-Server auf dem Router muss natürlich abgeschaltet werden, nach dem Motto "Es kann nur einen geben" daf es nur einen DHCP-Server in einem Netz geben.
In der dnsmasq.conf kann ein log-dhcp die Ausgabe erhöhen.

Gruss, habakug

[MSfree]

Laut der Kommentare in der .conf ist das aber nicht notwendig.

Durch das Update von Wheezy auf Jessie hast du noch die alte Konfiguraiotnsdatei von Wheezy für dnsmasq auf deinem Rechner. In der Konfdatei, die ich hier auf einem Raspi mit Debian 8.0 laufen habe, steht nichts drin, was das Defaultverhalten angeht.

Ich würde an deiner Stelle wirklich mal die Zeile
interface=eth0
einfügen, um sicherzustellen, daß der wirklich auf eth0 lauscht.

An den beiden Ports würde ich mich nicht weiter fetsbeissen., es sei denn, du hast mit iptables Firewallregeln erstellt, die die Ports 67 und 68 sperren.

[Schultze]

Hallo!
Nur um es mal zu erwähnen: Der DHCP-Server auf dem Router muss natürlich abgeschaltet werden, nach dem Motto "Es kann nur einen geben" daf es nur einen DHCP-Server in einem Netz geben.

Das hatte ich ja anfangs gemacht und kam dann gar nicht mehr ins Netz. Deshalb probiere ich es ja nun mittels 'dhcping', bei dem man explizit den Server angeben kann.

In der dnsmasq.conf kann ein log-dhcp die Ausgabe erhöhen.

Das habe ich probiert (ist auch aktuell in der .conf), ich finde jedoch nirgends ein entsprechendes Logfile.

[Schultze]

Durch das Update von Wheezy auf Jessie hast du noch die alte Konfiguraiotnsdatei von Wheezy für dnsmasq auf deinem Rechner.

Nein. Ist alles plattgemacht, sogar ein neues Filesystem ist drauf, nur /home habe ich behalten.

In der Konfdatei, die ich hier auf einem Raspi mit Debian 8.0 laufen habe, steht nichts drin, was das Defaultverhalten angeht.

Es gibt eine Default-Konfigurationsdatei. Die ist ellenlang und zeigt alle möglichen Parameter und wie diese sich auswirken.

Ich würde an deiner Stelle wirklich mal die Zeile
interface=eth0
einfügen, um sicherzustellen, daß der wirklich auf eth0 lauscht.

Wie ich oben bereits erwähnte, habe ich das natürlich längst ausprobiert.

Das Dumme ist ja wirklich, dass ich nirgends eine Fehlermeldung finde. Deshalb finde ich auch keinen Ansatzpunkt. Es sieht alles so aus, als ob der DHCP-Server korrekt läuft, aber er antwortet scheinbar nicht auf Anfragen.

Schultze

[MSfree]

Das Dumme ist ja wirklich, dass ich nirgends eine Fehlermeldung finde.

Stop den Dienst mit systemctl stop dnsmasq. Nur, um sicher zu gehen, daß wirklich kein dnsmasq mehr läuft, kille danach noch eventuell laufende dnsmasq-Daemons mit killall -9 dnsmasq. Danach führst du auf der Kommandozeile dmsmasq --test -C [NameDeinerConfigDatei] aus.

Sollte bei dem Test nichts herauskommen, kannst du dnsmasq auch zum Debuggen von der Kommandozeile starten und mitverfolgen: dmsmasq -dd -C [NameDeinerConfigDatei]

Dabei kannst du auch mitverfolgen, wenn Clients versuchen, sich per DHCP zu konfigurieren.

[Schultze]

Sollte bei dem Test nichts herauskommen, kannst du dnsmasq auch zum Debuggen von der Kommandozeile starten und mitverfolgen: dmsmasq -dd -C [NameDeinerConfigDatei]

Dabei kannst du auch mitverfolgen, wenn Clients versuchen, sich per DHCP zu konfigurieren.

Hallo und danke für den Hinweis. Ergibt aber für mich leider keine weitere Erkenntnis.

Code: Alles auswählen

# dnsmasq -dd -C /etc/dnsmasq.conf 
dnsmasq: started, version 2.72 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect
dnsmasq-dhcp: DHCP, IP range 192.168.42.111 -- 192.168.42.222, lease time 12h
dnsmasq: reading /etc/resolv.conf
dnsmasq: using nameserver 192.168.42.1#53
dnsmasq: read /etc/hosts - 5 addresses

dnsmasq-dhcp: 485389910 available DHCP range: 192.168.42.111 -- 192.168.42.222

Die letzte Zeile kam durch den Request eines Clients hinzu, der aber nach wie vor keine Antwort erhält.
Es scheint mir so, als ob die Antwort des DHCP nicht raus geht.

In den FAQ habe ich folgendes gefunden:

Code: Alles auswählen

Q: This new DHCP server is well and good, but it doesn't work for me.
   What's the problem?

A: There are a couple of configuration gotchas which have been
   encountered by people moving from the ISC dhcpd to the dnsmasq
   integrated DHCP daemon. Both are related to differences in 
   in the way the two daemons bypass the IP stack to do "ground up"
   IP configuration and can lead to the dnsmasq daemon failing
   whilst the ISC one works.

   The first thing to check is the broadcast address set for the
   ethernet interface. This is normally the adddress on the connected
   network with all ones in the host part. For instance if the 
   address of the ethernet interface is 192.168.55.7 and the netmask
   is 255.255.255.0 then the broadcast address should be
   192.168.55.255. Having a broadcast address which is not on the
   network to which the interface is connected kills things stone
   dead.

   The second potential problem relates to firewall rules: since the ISC 
   daemon in some configurations bypasses the kernel firewall rules 
   entirely, the ability to run the ISC daemon does not indicate 
   that the current configuration is OK for the dnsmasq daemon.
   For the dnsmasq daemon to operate it's vital that UDP packets to 
   and from ports 67 and 68 and broadcast packets with source 
   address 0.0.0.0 and destination address 255.255.255.255 are not 
   dropped by iptables/ipchains.

Der letzte Absatz ist, denke ich, interessant. Könnte es sein, dass die Antworten des DHCP von einer Firewall geblockt werden?

Schultze

[MSfree]

The first thing to check is the broadcast address set for the ethernet interface.

Ich hoffe, dem Tip bist du schon nachgegangen.

Der letzte Absatz ist, denke ich, interessant. Könnte es sein, dass die Antworten des DHCP von einer Firewall geblockt werden?

Das hatte ich dich weiter oben indirekt auch schon gefragt. Ich zitiere mich nochmal:

An den beiden Ports würde ich mich nicht weiter fetsbeissen., es sei denn, du hast mit iptables Firewallregeln erstellt, die die Ports 67 und 68 sperren.

Führ mal iptables-save aus. Damit werden alle aktuell konfigurierten Filterregeln ausgegeben. (Keine Angst, das "save" im Namen verändert keine Datei auf deinem Rechner)

[Schultze]

Führ mal iptables-save aus. Damit werden alle aktuell konfigurierten Filterregeln ausgegeben. (Keine Angst, das "save" im Namen verändert keine Datei auf deinem Rechner)

Ich selbst habe keinerlei Firewall konfiguriert. Da verlasse ich mich auf die Automatismen bei der Installation von Debian.

Code: Alles auswählen

# iptables-save
# Generated by iptables-save v1.4.21 on Sun Dec 20 19:42:45 2015
*mangle
:PREROUTING ACCEPT [271:17329]
:INPUT ACCEPT [271:17329]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [180:20578]
:POSTROUTING ACCEPT [181:20651]
-A PREROUTING -p tcp -m tcp --dport 5555 -j DROP
COMMIT
# Completed on Sun Dec 20 19:42:45 2015
# Generated by iptables-save v1.4.21 on Sun Dec 20 19:42:45 2015
*filter
:INPUT ACCEPT [424:28861]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [291:31572]
COMMIT
# Completed on Sun Dec 20 19:42:45 2015

Ich erkenne daraus nichts.

Schultze

[MSfree]

Ich selbst habe keinerlei Firewall konfiguriert. Da verlasse ich mich auf die Automatismen bei der Installation von Debian.

Code: Alles auswählen

# iptables-save
# Generated by iptables-save v1.4.21 on Sun Dec 20 19:42:45 2015
*mangle
:PREROUTING ACCEPT [271:17329]
:INPUT ACCEPT [271:17329]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [180:20578]
:POSTROUTING ACCEPT [181:20651]
-A PREROUTING -p tcp -m tcp --dport 5555 -j DROP
COMMIT
# Completed on Sun Dec 20 19:42:45 2015
# Generated by iptables-save v1.4.21 on Sun Dec 20 19:42:45 2015
*filter
:INPUT ACCEPT [424:28861]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [291:31572]
COMMIT
# Completed on Sun Dec 20 19:42:45 2015

Ich denke, der blockt praktisch alles ab. Wie bist du denn im Moment auf dem Rechner eingelogt?

Die Firewallregeln, die zu zufügen müßtest, damit dnsmasq funktioniert, sind:

iptables -i eth0 -A INPUT -p udp --dport 53 -j ACCEPT
iptables -i eth0 -A INPUT -p udp --dport 67:68 -j ACCEPT

Du kannst die Firewall natürlich auch (erstmal) komplett abschalten mit iptables -F.

[rendegast]

Hier bekomme ich auch keine Antwort dhcping -> dnsmasq.
(jessie)
Adressen werden aber definitiv vergeben.

Ups, habe auf dem Client eine Bridge, so geht es

Code: Alles auswählen

# dhcping -i -c clientip -s serverip
Got answer from: serverip

So nicht:

Code: Alles auswählen

# dhcping    -c clientip -s serverip
no answer

[Schultze]

Ich denke, der blockt praktisch alles ab. Wie bist du denn im Moment auf dem Rechner eingelogt?

Ich bin dort per ssh eingeloggt.

Die Firewallregeln, die zu zufügen müßtest, damit dnsmasq funktioniert, sind:

iptables -i eth0 -A INPUT -p udp --dport 53 -j ACCEPT
iptables -i eth0 -A INPUT -p udp --dport 67:68 -j ACCEPT

Du kannst die Firewall natürlich auch (erstmal) komplett abschalten mit iptables -F.

Ich habe die Firewall also deaktiviert,

Code: Alles auswählen

# iptables-save
# Generated by iptables-save v1.4.21 on Mon Dec 21 09:47:12 2015
*filter
:INPUT ACCEPT [1270:92077]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [932:174900]
COMMIT
# Completed on Mon Dec 21 09:47:12 2015

aber das gleiche Verhalten wie zuvor.

Schultze

[MSfree]

Könntest du noch du Ausgabe von iptables -L -n -v posten?

[Schultze]

Könntest du noch du Ausgabe von iptables -L -n -v posten?

Gerne. Hier, bitte:

Code: Alles auswählen

# iptables -L -n -v
Chain INPUT (policy ACCEPT 3311 packets, 214K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1998 packets, 247K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Schultze

[eggy]

Ich denke, der blockt praktisch alles ab.

Wie kommst Du darauf?
Alles Policies stehen auf ACCEPT, und das Drop gilt nur für TCP auf Zielport 5555.

[MSfree]

Wie kommst Du darauf?

Jo mei, manchmal hat man auch einen schlechten Tag und schaut nicht so genau hin .

Wie dem auch sei, mir scheint dhcping und/oder die Testumgebung irgendwie nicht das Mittel zu sein. Im selben Netz läuft noch ein DHCP-Server auf dem Router. Ich würde jetzt einfach mal ein isoliertes Testnetz aufbauen, bestehend nur aus dem Rechner mit dem neuen DHCP-Server (dnsmasq), einem Testrechenr, der als DHCP-Client fungiert und eine Cross-Over-Patchkabel zwischen den beiden.

Bei Gigabit-Netzwerkschnittstellen wird keine Cross-Over-Kabel benötigt, weil die Netzwerkschnittstellen selbst Mediasense durchführen und die Signale ggfls. intern umdrehen. Wahlweise, wenn vorhanden, kann man auch einen kleine Switch/Hub verwenden, um das Testnetz aufzubauen.

Ich kann nur sagen, daß ich vor kurzem selbst dnsmasq mit Debian 8 auf einem Raspi eingerichtet habe und das lief auf Anhieb richtig. Die Testkonfiguration war in meinem Fall folgende

/etc/dnsmasq.conf:

Code: Alles auswählen

address=/#/172.16.0.1
interface=wlan0
domain=testdomain.ip
dhcp-range=172.16.0.10,172.16.255.254,12h
no-resolv
log-queries

Die "address"-Zeile bewirkt, daß der DNS für jede Adresse ausserhalb von "testdomain.ip" 172.16.0.1 zurück liefert, effektiv also immer auf den dnsmasq-Server leitet. Das muß für reale Funktionalität natürlich geändert werden.

/etc/network/interfaces:

Code: Alles auswählen

auto wlan0
iface wlan0 inet static
        address 172.16.0.1
        netmask 255.255.0.0
        broadcast 255.0.0.0

Statt wlan0, wie in meinem Fall, muß natürlich im Fall des OP eth0 eingetragen werden.

[eggy]

@Schultze: poste doch bitte nochmal die Config, so wie Du sie zur Zeit verwendest.