-
-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PhoneBlock Anrufbeantworter nicht erreichbar #81
Comments
Nach dem Umzug von PhoneBlock zu einem Hostingprovider, hat der Dienst jetzt feste IP-Adressen. Ich arbeite aber immer noch an der Stabilität - siehe #85. |
Ich vermute ähnliches. Ich schalte meine Box auch immer über Nachts aus. Diese Meldung tauchte um 8:11 auf (um 8:00 schalte ich die Box ein): Wenn ich dagegen manuell einen Reconnect in der FB mache, erfolgt dementsprechend natürlich auch keine sofortige Anpassung im DynDNS. Es dauert min. 10min bis die ipv4 Adresse angepasst wird. Aber vorher schon nach 8min. wirft die FB die obige Fehlermeldung mit der DNS-Auflösung auf. In der Zwischenzeit fehlt ebenso die ipv4 Adresse im dyndns dns record. Vielleicht kann man es zuverlässiger über ipv6 machen, da wechselt die Adresse nämlich nicht so häufig. Oder es gibt generell ein Problem mit wechselnden ipv4 Adressen. Vielleicht bekommt dein Server gar nichts von der Adressänderung mit oder gibt nach ein paar Minuten von selbst auf. |
Danke für den Hinweis - mit dem nächtlichen Ausschalten der Box bist Du ein guter Testkandidat. Reduzierung der TLL ist kein Problem - ich vermute alledings noch ein weiteres Problem, denn die DNS-Auflösung des Hostnamens ist nur für die Fritz!Box selber wichtig, damit sie "alles OK" anzeigt und nicht ständig eine neue Registrierung durchführt. Wenn die Box die Adresse übermittelt hat, ist diese PhoneBlock bekannt - hierfür wird dann keine DNS-Abfrage mehr gemacht. |
Ich hatte den DynDNS mit einem Online Tool getestet z.b. |
Das PhoneBlock-Log sagt dazu folgendes: Die Box meldet sich (erst um) 08:36:02 mit ihrer neuen IPv6 Adresse (ohne eine IPv4 Adresse zu übermitteln):
Ein zweites Mal meldet sie sich dann um 08:40:03 mit der IPv4 und IPv6-Adresse:
Das erklärt zumindest, warum mindestens von 8:00 bis 8:36 der Anrufbeantworter nicht funktionieren kann. Und warum das DNS zuerst nur die IPv6 Adresse kennt. Allerdings erklärt es nicht, warum sich die Situation danach nicht wieder "erholt". Die Logs sagen, dass PhoneBlock weiterhin versucht den Anrufbeantworter mit der alten IPv6-Adresse zu registrieren - das kann natürlich nicht funktionieren. Nachtrag: Weiter oben in den Logs sieht man auch, dass diese spezielle Box ständig ihre IPv4-Adresse wechselt - mal löscht sie die Adresse mal registriert sie eine neue Adresse. Das scheint mir am Internet-Provider zu liegen, der keine auch nur annähernd stabile Versorgung mit IPv4-Adressen bietet. Für PhoneBlock ist das aber egal, wenn möglich, wird immder die IPv6-Adresse bevorzugt. |
Die ipv4 Adressen wechseln aufgrund der Knappheit bei so gut wie allen ISP nach jedem Reconnect d.h. spätestens bei der Zwangstrennung, während ipv6 deutlich länger erhalten bleibt. An SIP Session Timer dürfte es eigentlich auch nicht liegen, die sind i.d.R. auf max. 1Std. eingestellt. |
Habe eine neue Version deployt. Es wird jetzt nach einem fehlgeschlagenen Registrierungsveruch ein Update der IP-Adresse durchgeführt, auch wenn diese über DynDNS übermittelt wurde. Werden wir sehen, wie die Situation morgen um 8:30 aussieht... |
versuch1: zusätzlichen AB ab-4727649445784xxx in phoneblock angelegt 13:34 reconnect |
Ich glaube das hat sich jetzt überschnitten mit den Änderungen. Was mir noch aufgefallen war das bei jedem Reconnect ein neuer ipv6 Präfix bezogen wird, ich kenne mich leider mit ipv6 nicht so gut aus. Und diese Fehlermeldung war zu sehen: |
Da der phoneblock dyndns Service plötzlich nicht mehr funktioniert, habe ich jetzt auf dyndns geswitched. |
Wie äußert sich das? Wie ist Deine aktuelle Anrufbeantworter-ID? Würde gerne herausfinden, was los ist. |
Ich habe mit meiner Box gerade nochmal getestet und die ablaufende Sequenz ist genau die, die ich erwarte: Die letzte erfolgreiche Registrierung
Neu-Verbinden - Die Fritz!Box registriert ihre neue IP
Die Anrufbeantworter-Anmeldung scheitert, weil IP geändert
Es wird eine neue Registrierung mit der geänerten IP gemacht
Die Fritz!Box überprüft, ob die neue Adresse über DNS aufgelöst werden kann:
|
Der dyndns hatte keine IP gespeichert, dementsprechend war ab-3414688686166xxx am 6.11 nicht mehr funktionsfähig. Aktuell nutze ich noip und mir ist aufgefallen das dort kein ipv6 funktioniert obwohl es in der Update URL steht: Der neue ab-2267936966576xxx über noip scheint aber jetzt zu funktionieren. Seltsam ist ja das der phoneblock dyndns bis zum 5.11 funktioniert hat (zumindest habe ich das so in Erinnerung) Evtl. ist der Fehler bei ipv6 zu suchen, die üblichen ipv6 Testseiten gehen bei mir aber. |
Ich probiere jetzt noch mal den alten AB ab-3414688686166xxx mit phoneblock dyndns. Um 12:37 Bezug neuer IP vom Provider. Über update url: Log: Um 12:52 Änderung Update Url auf ipv4 only: Was ich nicht nochmal getestet habe ob es mit ipv4 über DS-Lite funktioniert. Bin mir aber nicht sicher ob das jemals schon mal aktiv war. |
Die Log-Einträge dazu sind:
Zeiten sind UTC. |
Bis 11:56:44 (UTC) gibt es Unmengen von DNS-Abfragen für diese Adress (1647 Stück). Da scheint die Box irgendwie "durchzudrehen"... |
Die ipv6 Adresse ändert sich anscheinend doch beim reconnect, war mir gar nicht aufgefallen. Habe jetzt nochmal versucht die Update URL nur mit ipv6 zu machen, dies funktioniert ebenso! Und was mir noch aufgefallen ist, die FB meldet: Hat es etwas mit der Update URL und Fritz OS 8.0 zu tun? Wird meine Box aufgrund der vielen Anfragen womöglich sogar geblockt? |
Ich "habe das Gefühl", dass die Fritz!Box "angemeldet" für den DynDns-Status meldet, wenn es keinen Fehler bei dem Aufruf der Upate-URL gab und "erfolgreich angemeldet" wenn sie danach über einen DNS-Lookup verifiziert hat, dass die Adresse jetzt abrufbar ist - das kann eine Weile dauern, bis sich der Status von "angemeldet" auf "erfolgreich angemeldet" ändert. "Bei TTL 1min..." die Box macht aber nur so lange Abrufe, bis sie ihre Adresse über DNS auch gefunden hat - daher sollte das wenn alles andere funktioniert keine Probleme verursachen. Normalerweise macht ja niemand eine DNS-Abfrage mit der PhoneBlock-Adresse - außer die Box selber um die Anmeldung zu überprüfen. |
Aktuell gibt es eigentlich keine Hinweise, dass etwas nicht funktioniert. Alle Anrufbeantworter, bei denen die initiale Anmeldung geklappt hat (26) sind immer noch angemeldet. Davon nutzen 10 den eingebauten DynDNS-Dienst. Leider klappt bei ca. 30% die initiale Anmeldung nicht - da ist leider unklar, woran das liegt. |
Bei mir funktioniert nur einer dieser beiden Update URLs: Wenn ich die eigentliche gedachte bzw. originale URL mit ip4 und ip6 benutze dann fällt auch auf das sich die DNS Einträge ständig ändern wenn man sie be einem öffentlichen DNS abfragt. |
Hmm, echt komisch, was die Box hier macht. Das sind Deine Updates der letzten Tage:
|
Ich habe auch relativ viel rumprobiert, hat dein Server eine falsche Uhrzeit oder sind das UTC Zeiten? Mit ipv4&ipv6 (gestern umgestellt) funktioniert auch nichts. Wenn ich nur ipv6 nehme, dann bekomme ich zum AB wenigstens eine Verbindung. Diverse DNS Tools melden auch erst nach ca. 10min einen AAAA record zu fb-5962335596464xxx.box.phoneblock.net Also da stimmt definitiv was nicht mit der Übermittlung der dyndns Einträge. Und auch bei der Verwendung von ip4 only erhalte ich Fehler. Der AB funktioniert jedoch auch hier erstmal. Die IP wird zum dyndns übermittelt und dann passiert nichts weiter. Der Name kann auch nach 10min nicht aufgelöst werden. Edit: |
Hallo Bernhard,
wir hatten ja schonmal per E-Mail geschrieben, das der Anrufbeantworter nach einem IP Wechsel nicht mehr erreichbar ist. Somit gehen natürlich die Anrufe wieder durch. Kannst du da keine feste IP oder eine Überprüfung einbauen? Immer dich anschreiben wenn es nicht geht, ist ja auch blöd. Danke.
The text was updated successfully, but these errors were encountered: