Anmeldung der Internetrufnummer nicht erfolgreich. Ursache: DNS-Fehler

[erik]

Also wenn ich bei meiner Fritzbox, die als Client läuft, das Lan-Kabel entferne stehen im Log lauter DNS-Fehler, außer bei der Nummer die sich intern bei einer anderen Fritzbox anmeldet, dort steht die IP-Adresse als Registrar drin und im Log heißt es dann Gegenstelle antwortet nicht Zeitüberschreitung.

Das Problem daß abgebrochene Verbindungsversuche ewig lange nicht wiederholt werden hatte ich mit älteren Firmwareversionen auch schon, im Moment gibt es da aber kein Problem. Es half nach meiner Beobachtung die Vergabe fester IP-Adressen an alle VoIP-Geräte im Netz (was derzeit die Verwendung der Wlan-Repeaterfunktion der Fritzbox ausschließt, da kann man die IP nicht mehr fest vergeben) und nach dem Update einmalig eine komplette Neukonfiguration zur Beseitigung von Altlasten.

 

[PeterPawn]

Das Problem, daß eigentlich funktionierende sipgate.de-Konfigurationen auf einer FRITZ!Box hinter einem Kabel-Modem nach einiger Zeit nicht mehr funktionieren und die Box an dieser Stelle einen "DNS-Fehler" meldet, ist nicht vollkommen neu und z.B. auch hier schon "erwähnt".

Solange sich niemand mit diesem Problem der Mühe unterzieht und es einmal genauer untersucht, wird sich das vermutlich auch nicht ändern. Ob die an der verlinkten Stelle propagierte Lösung (da ging es um die 06.50 der 7490, wenn ich mich richtig erinnere) hier auch praktikabel wäre, wage ich nicht einzuschätzen.

 

[AachenChris]

Ich habe das Problem auch schon sehr oft auf verschiedenen Boxen gesehen.
Aktuell habe ich es wieder, 7390, freetz trunk mit 6.86.
Immer das Gleiche: andauernde DNS Fehler Meldungen und wenn ich mich auf die Box einlogge und voipcfgchanged aufrufe geht es sofort wieder.
Kann es sein, dass der voipd sein eigenes DNS macht und da aus einem loop nicht mehr rauskommt?
Ich muss dazu sagen, dass ich dnsmasq mit im freetz habe, dies aber nicht starte.

 

[PeterPawn]

Kann es sein, dass der voipd sein eigenes DNS macht und da aus einem loop nicht mehr rauskommt?

Das kann nicht nur sein, das ist definitiv so und hier auch schon mehrfach thematisiert.

Was soll das denn für ein "Loop" sein? Oder ist das eher "geraten"?

Der "voipd" macht aber tatsächlich seine eigenen DNS-Abfragen und kann dafür sogar einen bestimmten Source-Port verwenden (Angabe "dnsport" in der "voip.cfg").

Damit reagiert AVM wohl darauf, daß bei einigen Konfigurationen die IP-Telefonie auch über eine gesonderte, virtuelle Verbindung geht, die ggf. sogar mit reservierten Adressen innerhalb des Providernetzes arbeitet und wo der zugehörige DNS-Server sich über "normale Internetverbindungen" gar nicht abfragen läßt bzw. "netzintern" andere Antworten gibt, als wenn er von außen befragt wird.

Aber um das Problem weiter einzugrenzen, muß man viiiiel mehr Einzelheiten der Konfiguration kennen ... denn da gibt es nur geringfügig weniger Einstellmöglichkeiten als Lotto-Kombinationen bei 6 aus 49.

Wenn hier außerdem Freetz noch (mit den alten Mechanismen) versuchen sollte, den "dnsmasq" (auch wenn er nicht gestartet ist) bei Bedarf "einschleusen" zu können (da wird dann verhindert, daß der AVM-Daemon "multid" sich beim Start die passenden Ports schnappt), könnte das Chaos perfekt sein (bei bestimmten Konfigurationen) ... diese ganzen Patch-Versuche stammen nämlich (afaik) noch aus einer Zeit, wo der "voipd" auch eher eine Randnotiz in der Firmware war.

Will man das Problem suchen, muß man halt mal ein paar Paketmitschnitte machen ... dabei aber eben auch darauf achten, welche DNS-Requests vom eingestellten Source-Port erfolgen und an welche DNS-Server diese gehen ... bis hin zu den erhaltenen Antworten.

Nur mit der Glaskugel wird da keiner wirklich helfen können ... zumal die 06.86 (auch wenn sie für die 7390 die letzte ist) schon stark angegraut ist und sich da bei AVM praktisch in jeder neuen Version seitdem auch etwas getan hat am "voipd" - wenn AVM auch wenige Einzelheiten "verkündet", kann man sich trotzdem die umfangreichen Änderungen am "voipd" schon aus den veröffentlichten Einzeilern einigermaßen zusammenreimen.

 

[AachenChris]

a) Es war eine Vermutung, dass der voipd DNS selbst macht, da zu dem Zeitpunkt, wo die andauernden DNS Fehlermeldungen auftauchen, das "normale" DNS problemlos funktioniert. Also muss es wohl am Standard DNS "vorbeigehen".
b) Mit Loop (auch eine Vermutung, ich habe die sources von voipd nicht) meine ich ein Zustand, in den der voipd gerät, aus dem er ohne Anstoßen (voipcfgchanged oder manuelle oder automatisches DSL/Internet reconnect) nicht mehr rauskommt.
c) Die sip Konfoguration ist standard sipgate basic, also keine Geheimnisse beim DNS ...
Sipgate selbst kennt das Problem auch und sie empfehlen dann einen proxy mit der fixen IP Adresse anzugeben. Damit ist man natürlich das Problem los.
d) An 6.86 komme ich leider nicht vorbei.
e) Ich erwarte eher nicht, dass freetz und das nicht-laufende dnsmasq das Problem ist. Ich habe einmal die Ports überprüft und nichts ungewöhnliches endeckt:
multid 1073 root 12u IPv6 2137 0t0 UDP *:53
multid 1073 root 13u IPv6 2138 0t0 UDP *:54708
multid 1073 root 15u IPv6 2147 0t0 UDP *:47362
multid 1073 root 19u IPv4 2181 0t0 UDP *:67
multid 1073 root 25u IPv6 2300 0t0 UDP *:5355
multid 1073 root 26u IPv6 2301 0t0 UDP *:5353
multid 1073 root 27u IPv6 2302 0t0 UDP *:5355
multid 1073 root 28u IPv6 2303 0t0 UDP *:5353

voipd 2603 root 8u IPv6 8240 0t0 UDP *:7077
voipd 2603 root 12u IPv6 8242 0t0 UDP *:5060
voipd 2603 root 13u IPv6 8243 0t0 TCP *:5060 (LISTEN)

f) Ich kann beim nächsten Fehlerfall Paketmitschnitte anfertigen. Jedoch ist mir nicht klar, wie ich feststellen können sollte, welcher Prozess gerade eine nach außen gehenden DNS Anfrage inittiert. Der source port wird doch zufällig sein, oder hat voipd da einen fixen port?

 

[PeterPawn]

Man sieht es auch in Deiner Auflistung der Ports ... denn wozu sollte der "voipd" ansonsten an den Port 7077 gebunden sein? Da kommen die Antworten auf DNS-Abfragen (mit Source-Port 7077) i.d.R. ja wieder an - zumindest unter bestimmten Voraussetzungen. Wenn da kein "listen" angezeigt wird (wie beim TCP-Port), liegt das in der Natur der Anzeige bzw. der Websocket-Programmierung.

Wobei für eine sipgate-Nummer tatsächlich die "normale Internet-Verbindung" für die DNS-Abfrage genutzt werden sollte (und da wird iirc die Anfrage dann auch nicht unbedingt vom Port 7077 gesendet).

Nur würde so eine "normale" DNS-Abfrage (bei vorhandener Internet-Verbindung jedenfalls) ja auch kaum scheitern und damit wäre der "DNS-Fehler" erst recht vollkommen unerklärlich ... also wird wohl irgendeine Einstellung nicht passen.

Hast Du bei der betreffenden Nummer die Option "Anmeldung immer über eine Internetverbindung" aktiviert? Welche IP-Protokollversion wird für den SIP-Account tatsächlich benutzt (notfalls im REGISTER in den Support-Daten nachsehen, wenn bei den Einstellungen "entweder oder" erlaubt ist)? Was für ein Anschluß ist das überhaupt, d.h. welche Protokollversionen unterstützt der Provider tatsächlich?

 

[AachenChris]

1. Der Eintrag für die Telefonie ist über den Assistenten für sipgate erfolgt, dieser aktiviert dann auch "Anmeldung immer über eine Internetverbindung".
2. Ich hatte mich schon gefragt, wofür 7077 überhaupt gut sein soll; jetzt weiß ich es und das macht den Netzwertrace ja einfacher (ich weiß allerding nicht, warum die den Source Port überhaupt festlegen ...)
3. Die grundsätzliche Konfiguration sollte wohl in Ordnung sein, denn in 99% der Zeit funktioniert ja alle. voip.cfg habe ich (ohne username und passwrd) angehängt
4. Derzeit warte ich auf den Fehler, natülich taucht er erst einmal nicht mehr auf. Ich werde dann Paketmitschnitte auf den interfaces lo und dsl machen.

 

[PeterPawn]

ich weiß allerding nicht, warum die den Source Port überhaupt festlegen

Weil der Traffic dann anhand des Source-Ports "klassifiziert" werden kann (i.d.R. als "SIPDNS") und ggf. (wo nötig) anhand dieser Klassifikation dann QoS-Kriterien unterworfen oder über andere Interfaces gesendet werden kann, obwohl intern ggf. alles von ein- und derselben Source-IP (nämlich der der Box selbst) kommt.

Irgendwie muß die Box ja bei mehreren "virtuellen" Interfaces unterscheiden, welcher Kapselung Pakete zu unterziehen sind oder welche Adressen beim NAT verwendet werden müssen.

Wenn z.B. VoIP bei einem Provider über ein zusätzliches Interface mit privaten Adressen abgewickelt wird, setzt ja erst der "(k)dsld" das von der üblicherweise verwendeten lokalen IPv4-Adresse per NAT auf eine externe (nicht zwingend aber auch eine öffentliche) um. Ähnliches gilt z.B. auch, wenn TR-069 über ein weiteres Interface erreichbar sein soll ... usw.

 

[AachenChris]

Kapiert!
Ich warte jetzt auf den Fehler (wahrscheinlich wird er jetzt über Wochen erst einmal nicht mehr auftauchen ...).
Chris

P.S.: Muss ich bei (installierten) Version 6.86
"echo disable > /proc/net/avm_pa/control"
vor dem sniffing ausführen, damit mit tcpdump alle Pakete zu sehen bekommen, also keines verpasse?

 

[PeterPawn]

Sollte er alleine machen ... aber 06.86 ist schon sehr lange her und es gab zwischendrin auch mal Probleme, daß beim Mitschnitt der PA nicht abgeschaltet wurde bzw. die Pakete nicht zur CPU gespiegelt wurden und daher Teile des Ingress-Traffics auf der WAN-Seite fehlten.

DAS kann man aber problemlos schon vorher testen ... wenn eine HTTP-Verbindung von einem LAN-Client (nicht von der Box selbst) in voller Schönheit (mit dem Traffic in beiden Richtungen) im Mitschnitt erscheint, wird der PA entweder deaktiviert (was den Durchsatz bremst) oder die Pakete werden in Richtung CPU gedoppelt, nachdem die Hardware sie angepaßt und direkt zum Switch gesendet hat.

 

[AachenChris]

Natürlich:
Seit ich warte, trat der Fehler bisher nicht wieder auf ...