dyndns und dnsmasq

[astrapi]

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]

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]

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]

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]

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

 

[olistudent]

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]

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]

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]

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]

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

 

[cgabriel]

Solved!
I used these options in dnsmasq extra settings:

bind-interfaces
listen-address=192.168.178.1,192.168.179.1

Hope it helps.
MfG,
Gabriel

 

[olistudent]

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

Regards
Oliver

 

[RalfFriedl]

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]

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]

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]

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]

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

 

[olistudent]

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]

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]

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

I tried this combination:

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