dyndns und dnsmasq

astrapi · 10 Aug 2011

Hallo zusammen,

ich habe auf einer 7390 ein image mit dnsmasq (aktueller trunk, keine weiteren Pakete), sobald der dnsmasq gestartet ist, liefert mir dyndns (avm-webinterface) einen nicht näher beschriebenen Fehler. Stoppe ich dnsmasq, meldet sich die Box korrekt bei dyndns an.

Was braucht ihr um den Fehler zu analysieren?

olistudent · 10 Aug 2011

Ich bin mir nicht sicher. Vielleicht würde ein strace des multid helfen. Ich befürchte, dass AVM die dyndns Funktion abschaltet, wenn Port 53 beim multid Start durch dnsmasq belegt ist. In den letzten Tagen hab ich vermehrt von solchen Problemen gelesen.

Gruß
Oliver

GrafHawk · 22 Sep 2011

Der Thread ist nicht mehr ganz frisch, aber ich hab auch etwa seit dieser Zeit das Poblem.
Die Ursache scheint darin zu bestehen, dass dnsmasq auch (wie der Name schon sagt) dass dns über Port 53 übernimmt.
Wenn es das tut, funktioniert DynDNS nicht mehr.
Änder ich die Port-Nummer im dnsmasq auf z.B. 1053 geht auch DynDNS wieder.

Ich benutze die Firmware 54.05.05freetz-devel-7661 aus dem trunk auf einer 7270.
Als einziges Paket habe ich das dnsmasq ausgewählt.
Alle anderen Einstellungen sind unverändert.

hermann72pb · 22 Sep 2011

Kann es bei meiner 7270 ebenfalls bestätigen. Nach der Änderung der Portnummer meldet sich der AVM-ddns direkt und sofort beim Server, ohne sogar dass reconnect oder reboot nötig wären.
Und nun? Was können wir dagegen tun? Wie kann man multid dazu bringen zu glauben, er sei der alleinige Besitzer vom Port 53?

MfG

GrafHawk · 22 Sep 2011

Wie war das denn früher?
In früheren Freetz-Versionen ging das.
War das ein älteres dnsmasq?

olistudent · 22 Sep 2011

Nein, das war ein älteres AVM-Image. Ich bin ja AVM schon dankbar, dass der multid nicht mehr crasht, wie in den Labor-Versionen...

@hermann
Es wäre eventuell möglich den multid mit einer Preload Lib auf einen anderen (freien) Port zu binden. Welche Auswirkungen das hat müsste man probieren.

Gruß
Oliver

GrafHawk · 22 Sep 2011

olistudent schrieb:
Nein, das war ein älteres AVM-Image.

Das erklärt auch, dass das in der 7170 (neuester Stand) noch geht.
Das ist ja auch ne Version 4.

wengi · 7 Okt 2011

olistudent schrieb:
Ich bin mir nicht sicher. Vielleicht würde ein strace des multid helfen.

Hi,

ich habe auch die Probleme mit dyndns und dnsmasq auf einer 7390.
Nun habe ich ein image mit strace gebaut und könnte Dir behilflich sein.
Wann und wie genau soll ich den strace machen? Oder hat es sich erledigt?

BTW habe ich das Problem über onlinechanged.cgi und einem Skript wie hier beschrieben umgangen.

hermann72pb · 7 Okt 2011

2.PVC kannst du nur mit dem AVM-Klient updaten. Bzw. man muss da etwas anderes Einbauen.
Und nein, das Problem ist immer noch nicht gelöst.
Der andere Vorschlag von Oliver klingt für mich viel versprechender. Wenn man es allerdings wüsste, wie man den multid auf einem anderen Port binden kann....

MfG

RalfFriedl · 7 Okt 2011

Man könnte die Idee mit PRELOAD aufgreifen, die schon mal irgendwo erörtert wurde.

cgabriel · 8 Okt 2011

Solved!
I used these options in dnsmasq extra settings:

Code:

bind-interfaces
listen-address=192.168.178.1,192.168.179.1

Hope it helps.
MfG,
Gabriel

olistudent · 8 Okt 2011

I don't see the relation to the other post? Perhaps you can give some more info?

Regards
Oliver

RalfFriedl · 8 Okt 2011

Die Idee ist vermutlich, dass sich der multid an allgemeine Adresse 0.0.0.0:53 bindet und man diesen auch weiterhin auf diesem Port laufen lässt. Der dnsmasq bindet sich an die spezielle Adresse 192.168.178.1:53. Wenn eine Anfrage aus dem Netz 192.168.178.0/24 kommt, wird 192.168.178.1:53 bevorzugt, die Anfrage geht an dnsmasq, obwohl multid seinen DNS-Port offen hat.

cgabriel · 8 Okt 2011

olistudent schrieb:
I don't see the relation to the other post? Perhaps you can give some more info?

Regards
Oliver

Sorry,I was so happy that dyndns is working that I just quickly posted it...
Yes, the problem comes because multid (or something else) fails when port 53 is taken...
I just forced dnsmasq to listen to lan/guest only, and skip the loopback.
It seems that avm needs for whatever reason port 53 on localhost...
Moreover, other services also seem to also fail; I have at least problems with the time update, after a reboot the time was not updated until I stopped dnsmasq for a few seconds...

For me this is the solution I needed. Using another dyndns client is no solution because I want to publish the 2nd(tel) IP; only AVM client can do this.

BTW, there was a discussion about my patch to the dyndns client: http://www.ip-phone-forum.de/showthread.php?t=235398
I understood that it might be eventually integrated into freetz; is there anything against it?

Regards,
Gabriel

cgabriel · 8 Okt 2011

RalfFriedl schrieb:
Die Idee ist vermutlich, dass sich der multid an allgemeine Adresse 0.0.0.0:53 bindet und man diesen auch weiterhin auf diesem Port laufen lässt. Der dnsmasq bindet sich an die spezielle Adresse 192.168.178.1:53. Wenn eine Anfrage aus dem Netz 192.168.178.0/24 kommt, wird 192.168.178.1:53 bevorzugt, die Anfrage geht an dnsmasq, obwohl multid seinen DNS-Port offen hat.

I assume that dnsmasq binds before multid, otherwise we would get dnsmasq errors and not from avm services.
Restricting dnsmasq to internal network allows multid to also bind; I don't know exactly how but it is happy with limited binding...

Gabriel

RalfFriedl · 8 Okt 2011

Ich vermute, dass multid vor dnsmasq gestartet wird, weil alle Mod-Programme erst recht spät in der Boot-Sequenz gestartet werden. Unabhängig davon sind die Adressen verschieden, so dass beide Bind-Aufrufe erfolgreich sind.
Ich habe aber mal erst von Überlegungen gelesen, das im Kernel zu verhindern, weil das auch eine Sicherheitslücke sein kann, wenn ein Server regulär läuft und ein anderes Programm über die spezifischen Adressen die hereinkommenden Verbindungen annehmen kann.

cgabriel · 8 Okt 2011

Sorry, but it doesn't seem to work stable...

olistudent · 8 Okt 2011

dnsmasq wird deshalb extra früh gestartet. Außerdem gibt es einen multid Wrapper, der ihn anhält bevor dnsmasq gestartet wird.

Gruß
Oliver

RalfFriedl · 8 Okt 2011

Dass es den Wrapper gibt, wusste ich, dass dnsmasq normalerweise vor multid gestartet wird nicht.

Mit diesem Bind kommt es aber gar nicht darauf an, welches Programm zuerst gestartet wird, weil es sich um verschiedene Adressen handelt, die gebunden werden. Der multid ist zufrieden, weil er seinen Port hat und der dnsmasq bekommt aber die Anfragen.

@cgabriel
Bleibt noch die Frage, was da nicht stabil läuft.

cgabriel · 8 Okt 2011

It means I still get errors... even if it appeared to work at the beginning.

I tried this combination:

Code:

bind-interfaces
listen-address=192.168.178.1,192.168.179.1
except-interface=lo
interface=lan

But I get some errors about a binding to an interface.
Can someone explain/fix?

If not working, the only solution would be to listen on a virtual IP... would it be possible?

Gabriel

dyndns und dnsmasq

Mitglied

IPPF-Urgestein

Neuer User

IPPF-Promi

Neuer User

IPPF-Urgestein

Neuer User

Mitglied

IPPF-Promi

IPPF-Urgestein

Neuer User

IPPF-Urgestein

IPPF-Urgestein

Neuer User

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

IPPF-Urgestein

Neuer User

Statistik des Forums