Fragen zur Handhabung von dnsmasq

ZBeeblebrox

Neuer User
Mitglied seit
4 Jan 2008
Beiträge
22
Punkte für Reaktionen
0
Punkte
0
Hallo,

ich verwende eine Fritz!Box 7170 aktuell mit der Firmware 29.04.67freetz-1.0.2-3124.

kann es sein, dass man die Einstellungen (z.B. PC Name) unter "System -> Netzwerk" des AVM-Interfaces nicht mehr anfassen darf, wenn dnsmasq verwendet wird?

Ich habe das Problem, dass bei einer Änderung an dieser Stelle der dnsmasq-Prozess beendet wird und somit meine festen IP-Adressen und DNS-Einträge aus der Hosts-Datei nicht mehr beachtet werden.

Ist es generell eher eine "wackelige" Angelegenheit, den dnsmasq zu verwenden oder klappt das bei Euch stabil? Als ich das Ganze vor ein paar Monaten probierte, waren meine Erfahrungen damit eher ernüchternd. Aber vielleicht mache ich ja auch etwas falsch.

Gruß & Danke für den netten Fritz!Box-Mod ;)
 
Du solltest als erstes AVM-DHCP-Server abschalten! Das ist vermutlich dein Problem:
avm_dhcp_off.jpg
Zwar "hackt" sich dnsmasq vor dem AVM-DHCP-Server, sodass er als DHCP-Server die Regie übernehmen sollte, es ist aber immer noch eine "hack"-Lösung die dir nicht 100% garantieren kann, dass der AVM-DHCP-Server sich irgendwann mal wieder "durchboxt". Das passiert genau dann, wenn du im AVM-WebIF an den DHCP-spezifischen Einstellungen fummelst. Denn spätestens beim abspeichern deiner Änderungen im AVM-WebIF wird AVM-DHCP-Server neu gestartet und gewinnt dann gegenüber dem dnsmasq.
Deswegen mach es so, wie im Bild gezeigt von der AVM-Seite und verwalte deine sonstigen DHCP-Einstellungen über FREETZ-GUI. Dort gibt es erstens dnsmasq-GUI und dann noch die "hosts", wo du deinen hosts anhand der MAC-Adresse nach Wunsch IPs fest vergeben kannst.
Es geht sogar weiter. Wie du siehst, fängt bei mir der DHCP-Bereich erst bei 20-ger Adresse an (typische AVM-Einstellung). Ich habe aber einem meiner Rechner erfolgreich die xx.10-Adresse über hosts vergeben. Also, für "hosts" gilt die Einschränkung nicht, sie besagt lediglich, aus welchem Pool die neuen noch unbekannten Rechner ihre IPs bekommen.
Die AVM-Netzwerkseite mit den ganzen Namen und IP-Adressen lässt du nachher bitte in Ruhe und betrachtest sie nur rein passiv. Deine Namen, Zuordnungen MAC-IP usw. werden auch auf AVM-WebIF irgendwann mal zu sehen sein. Aber eben passiv, bitte da nichts verändern. Es darf nur einen DHCP-Server existieren.
Und noch zum Schluss über Erfahrungen: Ich benutze dnsmasq schon seit Jahren noch mit 7050, jetzt mit 7170 und bin damit tiefst zufrieden. Zwar nähert sich AVM mit ihren Firmwares langsam etwas näher dem, was dnsmasq kann, aber ganz fertig ist AVM damit noch nicht. Z.B. kannst du kaum unter AVM-DHCP-Server die IP ändern. Den Namen schon, aber nicht die IP.

MfG
 
Also ich hab auch Probleme mit dnsmasq. Wenn ich eine der Konfiguartionen ändere, macht die Box "dicht", dh kein ping, telnet, ssh usw. Telefon funktioniert noch. Nach ein paar Minuten rebootet sie dann und die neue Konfiguration ist übernommen. Deshalb ändere ich wenn möglich alles per Hand und reboote. Das war auch schon auf der 7170 so. Den AVM-DHCP hatte ich schon immer aus
Ansonsten kein Problem damit :-]
 
Die AVM-Netzwerkseite mit den ganzen Namen und IP-Adressen lässt du nachher bitte in Ruhe und betrachtest sie nur rein passiv. Deine Namen, Zuordnungen MAC-IP usw. werden auch auf AVM-WebIF irgendwann mal zu sehen sein. Aber eben passiv, bitte da nichts verändern.
Das ist nicht richtig. Man kann problemlos die Namen der Clients im AVM-Webif verändern, etc.
Es reicht also unter System > Netzwerk > IP-Einstellungen > IP-Adressen den DHCP-Server zu deaktivieren.

Und noch zum Schluss über Erfahrungen: Ich benutze dnsmasq schon seit Jahren noch mit 7050, jetzt mit 7170 und bin damit tiefst zufrieden. Zwar nähert sich AVM mit ihren Firmwares langsam etwas näher dem, was dnsmasq kann, aber ganz fertig ist AVM damit noch nicht. Z.B. kannst du kaum unter AVM-DHCP-Server die IP ändern. Den Namen schon, aber nicht die IP.
Der Unterschied und die Vorteile sind nicht von der Hand zu weisen. Ich sehe auch nicht, dass die AVM-Variante da irgendwie mit ihrer Funktionalität an dnsmasq gelangt.
 
Du solltest als erstes AVM-DHCP-Server abschalten! Das ist vermutlich dein Problem: [...]
Daran liegt es nicht, denn der DHCP-Service aus dem multid (also der AVM-Dienst) läuft bei mir nicht. Es wäre ja zu schön, wenn's so leicht wäre... ;)

Mit der aktuellen Firmware und Freetz 1.0.2 läuft es bisher gut. Man darf halt nur nicht an der eingangs erwähnten Stelle einen PC umbenennen. Dass dieser PC-Name nichts mit der Namensauflösung per DNS zu tun hat, ist mir bekannt. Es ist nur eine Erleichterung, wenn dort statt z.B. "PC-10.3.8.21" eben der aussagekräftigere Name "pc-hanswurst" steht. Somit ist die Zuordnung der Port-Forwardings etwas übersichtlicher.

Lange Rede, kurzer Sinn. Wenn man also einen PC dort umbenennt, passiert folgendes:

Situation vor der Namensänderung (alles läuft):
Code:
 4044 nobody     904 S    dnsmasq -p 53
 4054 root      2332 S    multid

Nachdem ich den PC-Namen im AVM-Interface geändert habe, sahen die PIDs so aus (es läuft kein dnsmasq mehr, multid wurde neu gestartet):
Code:
  828 root      2344 S    multid

Danach über das Freetz-Interface den dnsmasq wieder gestartet und die PIDs sind folgende (beide Dienste sind da, multid wurde nochmals neu gestartet - und zwar nach dem dnsmasq):
Code:
  984 nobody     896 S    dnsmasq -p 53
  987 root      2332 S    multid

Der multid wird also von irgend einem Skript aus dem AVM-Teil der Firmware bei solchen Änderungen neu gestartet und eben dieses (mir noch unbekannte) Skript scheint wohl auch den dnsmasq abzuschießen.
 
Wie gesagt, dann eben die Namen nicht ändern, oder diesen multid-Hack irgendwie anders lösen. Diese Hack-Lösung mit multid funktioniert genau so, wie du es zitierst: multid wird gekillt, dann dnsmasq gestartet und erst danach multid wieder gestartet. Das erkennt man an pid-s. Übrigens die Lösung existiert schon seit mehreren Jahren und stammt meineswissens von danisahne selbst. Normalerweise sollte da sogar multid gepatcht sein. Es sei denn, AVM hat multid verlegt oder was auch immer. Wenn du Lust hast, kannst du es checken, FREETZ-Quellen sind ja zugänglich. Es muss da irgendwo einen wrapper für multid existieren und multid-binary von AVM sollte irgendwo unzugänglich in einem Unterverzeichnis liegen.

MfG
 
Der Knackpunkt ist: Warum wird dnsmasq von einem Teil der Original-Firmware gekillt, obwohl dieses Programm in der Original-Firmware gar nicht vorhanden ist? Meiner Meinung nach kann das eigentlich nur ein Bug im Freetz-Mod sein, der bisher noch nicht behoben wurde.
Selbst wenn der multid nach einer Änderung neu gestartet wird, sollte das den dnsmasq gar nicht beeinflussen, da der multid ja ohnehin nach dem dnsmasq gestartet wird.

Jetzt habe ich beobachtet, dass nach so einer Namensänderung der multid sogar mindestens 2x neu gestartet wird.

Vorher:
Code:
 1256 nobody     900 S    dnsmasq -p 53
 1262 root      2332 S    multid

Kurz danach wird multid mit dem Parameter "-s" gestartet:
Code:
 1256 nobody     900 S    dnsmasq -p 53
 1514 root      1196 S    /bin/sh /etc/init.d/rc.net reload multid
 1537 root      1172 S    /bin/sh /mod/pkg/dnsmasq/usr/lib/dnsmasq/bin/multid -s
 1540 root      2232 S    multid -s

Am Ende läuft nur noch multid, diesmal ohne Parameter:
Code:
 1609 root      2336 S    multid

/mod/pkg/dnsmasq/usr/lib/dnsmasq/bin/multid:
Code:
#!/bin/sh
PATH=/bin:/usr/bin:/sbin:/usr/sbin

stop=0
args=$@

set -- $(getopt s $@ 2> /dev/null)
while [ $# -gt 0 ]; do
        [ "$1" == "-s" ] && stop=1
        shift
done

if [ "$stop" -eq 0 -a -z "$(pidof dnsmasq)" ]; then
        /mod/etc/init.d/rc.dnsmasq >> /var/log/mod_net.log
fi

multid $args

if [ "$stop" -ne 0 -a ! -z "$(pidof dnsmasq)" ]; then
        /mod/etc/init.d/rc.dnsmasq stop >> /var/log/mod_net.log
fi

So wie es aussieht, stoppt das Skript "/mod/pkg/dnsmasq/usr/lib/dnsmasq/bin/multid" den dnsmasq, startet ihn aber nicht wieder neu.

Dann habe ich "/var/log/mod_net.log" mit "tail -f" beobachtet. Dort erscheint nach dem Klick auf "Übernehmen" folgendes:
Code:
Stopping dnsmasq...done.
dnsmasq already started.

Er versucht den dnsmasq neu zu starten, aber das gelingt nicht. Da ist doch etwas faul...
 
Nach Klick auf Übernehmen, steht bei mir in der syslog:

Code:
Mar  8 08:14:17 fritz daemon.info dnsmasq[1633]: exiting on receipt of SIGTERM

Danach muss dnsmasq von Hand gestartet werden.
 
Es gab früher schon Probleme zwischen multid und dnsmasq. Es ging sogar genau in die Richtung von SIGTERM, dass multid den dnsmasq irgendwie killt oder wie auch immer. So habe ich es in Erinnerung. Deswegen wurde der oben zitierter wrapper geschrieben, der dann multid ersetzen sollte. D.h. wenn AVM multid aufrufen würde, wäre es abgefangen und dnsmasq wäre dann korrekt gestartet.
Jetzt ist es aber leider Gottes so, dass ich diesen Wrapper nicht mehr finde. Bei meiner 7170 mit einer der letzten FREETZ-Versionen (dnsmasq drin) sehe ich multid von AVM direkt unter bin (oder sbin), was darauf deutet, dass der wrapper gar nicht mehr zum Einsatz kommt. Kann da bitte einer der Entwickler dies erklären?

MfG
 
Es war wohl schon etwas spät, denn sonst hätte ich gemerkt, was der Parameter "-s" vom multid bedeutet... ;)

Meine aktuelle Einschätzung:
Etwas killt den dnsmasq, löscht aber die Datei "/var/run/dnsmasq.pid" nicht. Danach versucht "/mod/etc/init.d/rc.dnsmasq" dnsmasq zu starten, dies schlägt aber fehl, weil in Zeile 115 geprüft wird, ob eben jene .pid-Datei schon vorhanden ist. Da sie vorhanden ist, wird der dnsmasq nicht gestartet.

Wäre es nicht besser, an dieser Stelle statt gegen eine .pid-Datei, lieber mit "pidof dnsmasq" zu prüfen, ob der Prozess läuft?

Also Zeile 115 statt...
Code:
if [ -e "/var/run/dnsmasq.pid" ]; then
...lieber in...
Code:
if [ -n "$(pidof dnsmasq)" ]; then
...ändern?
 
Die Idee an sich ist nicht schlecht. Aber dies löst das Problem vom Grund her nicht, sondern schafft nur workarround. Man sollte es natürlich einpflegen, trotzdem würde ich der Ursache auf den Grund gehen. Denn normalerweise sollte der wrapper da sitzen und Aufrufe von multid abfangen. Dies tut er anscheinend nicht. Denn ich bin wie vor der Meinung, AVM-multid wird beim Abspeichern direkt aufgerufen, anstatt über wrapper und führt zum SIGTERM von dnsmasq. Hätte man da den wrapper, würde er für die richtige start-stop-Reihenfolge sorgen. Wie gesagt, da ist irgendwas schief mit dem wrapper.

Edit: Ich bin gerade durch die Sourcen durchgegangen und wenn ich es richtig verstanden hatte, ist diese Sache mit multid ziemlich krum gelöst. Eine saubere Lösung wäre einen sh-Skript in general-Patches-Dir. Mit diesem sh-Script sollte man dann abhängig vom gewählten dnsmasq als Paket dann AVM-multid in ein Unterverzeichnis AVM verschieben, wie es bei den wrappern üblich ist. Dann wird AVM-multid von AVM versteckt. Anstelle des multid sollte man den wrapper hinlegen oder wenigstens symlink auf diese unter libs tief versteckte Datei. Dann wird es sauber gelöst.
Momentan ist es durch diverse patches gelöst, die dann irgendwo die path-Variable ändern. Dies mag bedingt funktionieren, wenn aber AVM irgendwo auf die Idee kommt multid mit vollem Pfad anzusprechen, dann hilft die Lösung nicht und der Wrapper wird umgegangen. Das passiert wahrscheinlich hier. Ich vermute sogar, dass das Problem vermutlich nur bei neuen und Labor-Firmwares auftritt, weil AVM früher nie auf die Idee kam multid mit dem vollen Namen anzusprechen.

MfG
 
Zuletzt bearbeitet:
Mir stellt sich vor allem die Frage ,wie AVM es schafft, den dnsmasq zu beenden beim Neusetzen irgendwelcher Werte im AVM-Webinterface. "Normalerweise" wird doch der multid (Dann bzw. funktioniert das mit dem Wrapper nicht) mit nem SIGTERM oder SIGUSER(1|2) beendet werden. Notfalls mit nem SIGHUP, nur beendet das eignetlich keine anderne Prozesse. Ein restart des Ganzen sollte auch den dnsmasq neu starten, und zwar _vor_ dem multid.

Schwieirg halt beim Wrapper, wenn dann per Webinterface der multid (der das Wrapper-script) irgendwie mit Parametern gefüttert wird ;)
 
Mir stellt sich vor allem die Frage ,wie AVM es schafft, den dnsmasq zu beenden beim Neusetzen irgendwelcher Werte im AVM-Webinterface. [...]
Da ist schon eine Komponente von Freetz mit im Spiel, denn es wird ja auch versucht, den dnsmasq wieder zu starten. Also irgend ein Wrapper wird sicher aufgerufen. Mir fehlt nur im Moment die Zeit, das genauer zu untersuchen.

Vielleicht liest das ja einer, der sich in dem Knäuel etwas besser auskennt und nicht jeden Faden einzeln verfolgen muss. Ein kleiner Hinweis würde schon reichen. :)
 
/mod/pkg/dnsmasq/usr/lib/dnsmasq/bin/multid:
Code:
#!/bin/sh
...
if [ "$stop" -eq 0 -a -z "$(pidof dnsmasq)" ]; then
        /mod/etc/init.d/rc.dnsmasq [B]start[/B] >> /var/log/mod_net.log
fi

multid $args

if [ "$stop" -ne 0 -a ! -z "$(pidof dnsmasq)" ]; then
        /mod/etc/init.d/rc.dnsmasq stop >> /var/log/mod_net.log
fi

Da scheint das start zu fehlen, oder ist das der Default?

Wäre es nicht besser, an dieser Stelle statt gegen eine .pid-Datei, lieber mit "pidof dnsmasq" zu prüfen, ob der Prozess läuft?

Es gibt schon eine fertige Funktion (vermutlich in modlibrc), die zusätzlich zur Existenz der PID-Datei prüft, ob auch der Prozeß existiert.
 
Leute, ich sage es nochmal, da ist irgendwas schief mit dem wrapper, meiner Meinung nach. Ich kann mich dunkel erinnern, dass früher AVM-multid in einem Unterordner lag und seine Dienste über den Wrapper ausgeführt hat. Jetzt ist es definitiv nicht so. Der AVM-multid liegt direkt unter /sbin , deswegen weiß ich nicht, wie wrapper da überhaupt zum Einsatz kommen kann. Es wird zwar "path"-Variable in rc.net gepacht, dass der wrapper gefunden werden sollte, es reicht aber, wenn AVM den multid als /sbin/multid anspricht und der Wrapper ist umgangen. Genau das passiert meiner Meinung nach.
Wer war an dem multid letzte Zeit ran und warum wurde die Position des wrappers geändert?
Ich konnte leider im Track nichts dazu finden, da ich auch nicht weiß an welcher Stelle das Ersetzen von multid überhaupt geschah. Aber entweder bin ich so alt geworden und täusche es mir nur vor, oder multid war früher tatsächlich irgendwo anders.

MfG
 
@herman: Bist du sicher, dass es der Multid war? ich hatte damals temporär nen Wrapper für den ctlmgr gebastelt.
 
Wenn ich auf "Übernehmen" klicke, passiert Folgendes:

Code:
3345 root      1480 S    /bin/sh /etc/init.d/rc.net reload multid
 3368 root      1452 S    /bin/sh /mod/pkg/dnsmasq/usr/lib/dnsmasq/bin/multid -s
 3376 root      1468 S    /bin/sh /mod/etc/init.d/rc.dnsmasq stop
 3384 root      2468 R    multid -u

Auf der FritzBox gibt es 2 multid:

Code:
# find / -iname 'multid'
/sbin/multid
/usr/lib/dnsmasq/bin/multid

Wenn ich " /mod/pkg/dnsmasq/usr/lib/dnsmasq/bin/multid -s" mache, dann stoppe ich dnsmasq. Wenn ich nur "multid -s" mache, dann stoppe ich dnsmasq nicht.
Wofür wird "mod/pkg/dnsmasq/usr/lib/dnsmasq/bin/multid" benötigt? Denn dnsmasq kann auch ohne den multid-Prozess aktiv sein. Kann man "mod/pkg/dnsmasq/usr/lib/dnsmasq/bin/multid" nicht durch ein symlink auf "/sbin/multid" ersetzen?
 
@silent-tears: sicher bin ich mir nicht. Es könnte auch sein, dass es ctlmgr war. Ich kann mich nur erinnern, dass es im Suchverzeichnis (bin, sbin oder was ähnliches) ein Ordner namens "avm" angelegt war und drinnen lag das eigentliche Binary, der wrapper war eine Etage drüber, versteht sich. Ich hatte mich heute nur gewundert, als ich das nicht mehr finden konnte, obwohl es so um Weihnachten rum noch drin war.
Mag sein, dass es ctlmgr war, man könnte aber sowas auch für multid machen.

@sf3978: Unter mod-lib-haumichtot liegt der besagte wrapper, der unter anderem das binary /sbin/multid aufrufen soll. Einfach ersetzen geht es eben nicht, man muss schon Binary irgendwoanders hinlegen und aus dem wrapper drauf verweisen.

MfG
 
"mod/pkg/dnsmasq/usr/lib/dnsmasq/bin/multid" stellt sicher, dass der multid immer erst nach dem dnsmasq gestartet wird, indem es den multid nicht direkt startet, sondern statt dessen das init-Skript vom dnsmasq aufruft.

In eben diesem init-Skript finde ich keinen Code, der eine .pid-Datei anlegt oder entfernt. Interessant. Wo kommt die Datei dann her?

Wenn ich dnsmasq über das Freetz-Interface beende, bleibt die Datei "/var/run/dnsmasq.pid" erhalten. Ich habe sie zum Test gelöscht und den dnsmasq an der Konsole mit "dnsmasq -p 53" manuell gestartet und siehe da, die .pid-Datei war wieder da. :)

dnsmasq legt sie also selbst an, entfernt sie aber nicht, wenn er per SIGTERM beendet wird. Weil die Datei nicht automatisch entfernt wird, kann das init-Skript dnsmasq nicht erneut starten. Fehler gefunden?

Edit:
@hermann72pb:
Das Binary muss an keine andere Stelle verlegt werden, weil der Wrapper ansich ja funktioniert. Keine Ahnung, wie das genau gelöst ist. Das habe ich nun noch nicht auseinander genommen, aber es ist klar ersichtlich, dass eben dieses Wrapper-Skript aufgerufen wird, um den multid neu zu starten. Das ist aus meiner Sicht also völlig i.O.
 
Ist auch voll logisch. Die pid-Datei wird glaube ich irgendwo bei rc.dnsmasq angelegt und anschließend wieder gelöscht. Man muss es halt ordentlich als dienst starten und stoppen und nicht einfach killen oder zum Absturz bringen. Ich vermute, AVM checkt irgendwie, wer auf Port 53 lauscht und killt denjenigen dann einfach. Vermutlich macht das sogar multid selbst. Ist zwar hart und unüblich, aber was sollst...

Wie gesagt, wrapper nach silent-tears-Methode platzieren und alles ist in Butter.

MfG
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,295
Beiträge
2,249,594
Mitglieder
373,893
Neuestes Mitglied
Kukkatto
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.