[Sammlung] Sammelthema für FB 7580 mit Labor-Firmware "INTERN"

[Benares]

Hab meine drei auch gerade aktualisiert. Auf der Client-7580 wird jetzt in der Übersicht wenigstens die Bandbreite korrekt angezeigt. Aber das Problem mit den falschen Namen (PC-<MAC>, PC-<IP>) auf Clients und Repeatern besteht weiterhin. Neuer Bug, der hinzugekommen ist, die Router-7590 zeigt neben der dem 1750E selbst auch noch 2 "PCs" mit den MACs des Repeaters, jeweils für 2,4 und 5Ghz (PC-<MAC>)

 

[IngoKlein]

98-56383 Inhaus verfügbar

 

[Wotan-Box]

Wo ??? aber nicht auf dem AVM-Server

 

[stoney]

Natürlich auf einem AVM Server - wo denn sonst?

Wie suchst Du denn danach?!

 

[bastiks1988]

Hi

Habe mal einen Link gebastelt (hab ja eine 7590 und keine 7580 aber wollte es trotzdem mal wissen). Die Inhaus ist auf einem AVM Server. Hab die Inhaus gefunden.

Gruß
Basti

 

[Wotan-Box]

Sorry bin in Urlaub habe jetzt erst bemerkt das der FTP Zugriff gesperrt ist :-(

 

[koyaanisqatsi]

Was ? Im Urlaub kein "freies Internet" - Hölle Hölle Hölle
...ich mach nur da Urlaub, wo ich mit dem Administrator per Du bin

 

[PeterPawn]

wo ich mit dem Administrator per Du bin

Hier sieht man mal wieder, wie entscheidend so ein Leerzeichen sein kann: perdu

 

[Pom-Fritz!]

Die 6.98- 56886 ist online!

Seit dieser Version habe folgende Fehler im Log:

12.06.18 20:10:55 DynDNS-Fehler: Der angegebene Domainname kann trotz erfolgreicher Aktualisierung nicht aufgelöst werden.
12.06.18 20:10:55 DynDNS-Fehler: Die DynDNS-Aktualisierung war erfolgreich, anschließend trat jedoch ein Fehler bei der DNS-Auflösung auf.

Mein DynDNS Account ist bei Secure Point und als benutzerdefiniert eingetragen:

https://update.spdyn.de/nic/update?hostname=<domain>&myip=<ipaddr> https://update.spdyn.de/nic/update?hostname=<domain>&myip=<ip6addr>

Das hat bei der letzten Beta noch funktioniert!

Laut dem Log bei Secure Point wird die (gleiche) IP alle 30 Minuten neu von der Fritzbox gemeldet!! Das darf nicht sein!

 

[Cobold]

@Pom-Fritz!: Das habe ich bei meiner 7590er auch, auch bei Secure Point.
Ich denke aber nicht, dass es mit der neuen INTERN-Version zusammenhängt, denn bei meinen Eltern habe ich die Labor vom 08.06. drauf und dort gibt es seit gestern die gleiche Meldung und die Box ist nicht mehr erreichbar.

Aktuell habe ich keine Idee was da schief läuft.

 

[Pom-Fritz!]

Ich hatte gestern mal versucht, die Update-URL bei Secure Point anzupingen. Der Name wird zwar aufgelöst, aber ich habe 100% Paketverlust. Da wird wohl nicht auf ICMP geantwortet. Ist das denn so richtig?

Edit: Meine Synology DiskStation ist hier ebenfalls (mit anderen Hostnamen) gehostet. Hier läuft alles ohne Probleme.

Hier ein Log von Securepoint - Die Warnings sind erst ab 12.6.2018 vorhanden:

 

[PeterPawn]

die Update-URL bei Secure Point

???

Ist das jetzt tatsächlich "update.spdyn.de", was Du da anpingen wolltest und wenn ja, warum sollte die unbedingt auf ICMP antworten müssen?

Entscheidender ist doch die Frage, ob die DynDNS-Adresse richtig aktualisiert wird und bei nachfolgenden DNS-Abfragen aufgelöst werden kann ... die "Verweigerung" von ICMP-Paketen (mit "echo request" und "echo reply") ist vollkommen normal und liegt halt im Ermessen des Server-Betreibers (zumindest kann damit auch niemand mit falsch aufgebauten Paketen irgendwelchen Blödsinn treiben - das "Verstecken" macht bei einem Server ja weniger Sinn).

Wenn das Update bei Secure Point hingegen tatsächlich intern(!) nicht funktioniert (warum auch immer), dann stimmt die Meldung der FRITZ!Box ja vielleicht auch ... man muß ja nicht immer direkt die "Schuld" bei der neuen Firmware suchen (da hat #930 absolut recht).

Wenn die FRITZ!Box beim Versuch des Updates vom DynDNS-Server nicht die korrekte Antwort erhält, behauptet sie (in der Regel) auch nicht, daß das Update erfolgreich war - das deutet hier also zunächst mal eher auf einen Fehler des DynDNS-Betreibers hin (immer unter der Annahme, daß für das "Update" ein "good" gemeldet wurde und die nachfolgende Abfrage dann trotzdem eine andere Adresse liefert) und da sollte man mit der Fehlerdiagnose dann bei ihm beginnen und z.B. mal so einen Update-Request "von Hand" machen, um dessen Ergebnis zu überprüfen.

Ansonsten enthalten die Support-Daten auch noch ein sehr ausführliches Protokoll der Aktivitäten des - für DynDNS-Aktionen verantwortlichen - "ddnsd" ... das sollte man dann auch noch analysieren, bevor man die Verantwortung für das "Fehlverhalten" bei der Firmware festmachen möchte. Da kann noch so ziemlich alles schief laufen ... bis hin zu einem DNS-Hijacking, bei dem jemand die Adresse "update.spdyn.de" auf einen eigenen Server umlenkt (beim DynDNS-Update findet m.W. keine Überprüfung der "certificate chain" statt, auch wenn man HTTPS für die Aktualisierung verwendet) und dabei fleißig die Credentials (der DynDNS-Client konnte bisher nur "basic auth" tatsächlich nutzen, wenn ich mich richtig erinnere - zumindest war er von einer Aufforderung eines Apache2 zur "digest auth" restlos überfordert) beim Update mitliest und speichert.

 

[Pom-Fritz!]

Hallo, Peter

Danke für deine Ausführungen!

Ich habe natürlich das angepingt, was in der Update-URL stand - spdyn.de. Wie oben geschrieben gibt es keine Antwort auf ICMP, was aber dank deiner Erklärung durchaus richtig sein kann. Natürlich muss bei solchen Problemen nicht immer die neue Firmware schuld sein, aber laut dem Log von Secure Point sieht es so aus (#931). Erst am Datum des Software Updates (6.98-56886) treten hier Warnings auf!

Aber solche Zufälle kanns ja geben.

Ich habe hier mal einen Auszug aus den Supportdaten reingestellt. Den Interface Identifier (IPv6-Adressen) der F!B habe ich durch "zzzz" ersetzt, die IPv4 Adressen und der IPv6-Präfix ändern sich täglich.

[2018-06-12 20:54:20 v6 <userdefined> in]: Strict-Transport-Security: max-age=31536000
[2018-06-12 20:54:20 v6 <userdefined> in]: 2a
[2018-06-12 20:54:20 v6 <userdefined> in]: good 2003:73:d7f:8f40:zzz:zzz:zzz:zzz

[2018-06-12 20:54:20 v6 <userdefined> in]:
[2018-06-12 20:54:20 v6 <userdefined> in]: 0
[2018-06-12 20:54:20 v6 <userdefined> dbg]: ep=0x7782dc00 ddns_closecb:2482 updating -> updated
[2018-06-12 20:54:20 v6 <userdefined> dbg]: verify handle 2000671360 (delay 240)
[2018-06-12 20:58:20 v4 <userdefined> dbg]: dns_handle created 0x77443818 for 87.144.157.177
[2018-06-12 20:58:20 v6 <userdefined> dbg]: dns_handle created 0x774436d8 for 2003:73:d7f:8f40:zzzz:zzzz:zzzz:zzzz
[2018-06-12 20:58:20 v4 <userdefined> dbg]: ddns_verify_complete mit dns->handle 0x77443818
[2018-06-12 20:58:20 v4 <userdefined> dbg]: verify failed, is 87.144.156.229, but should be 87.144.157.177
[2018-06-12 20:58:20 v4 <userdefined> dbg]: verify failed: DNS reply: noerror -> retry verify in 240 secs
[2018-06-12 20:58:20 v6 <userdefined> dbg]: ddns_verify_complete mit dns->handle 0x774436d8
[2018-06-12 20:58:20 v6 <userdefined> dbg]: verify failed, is 2003:73:d7f:8326:zzzz:zzzz:zzzz:zzzz, but should be 2003:73:d7f:8f40:zzzz:zzzz:zzzz:zzzz
[2018-06-12 20:58:20 v6 <userdefined> dbg]: verify failed: DNS reply: noerror -> retry verify in 240 secs
[2018-06-12 21:02:20 v4 <userdefined> dbg]: dns_handle created 0x77443638 for 87.144.157.177
[2018-06-12 21:02:20 v6 <userdefined> dbg]: dns_handle created 0x77443a68 for 2003:73:d7f:8f40:zzzz:zzzz:zzzz:zzzz
[2018-06-12 21:02:20 v4 <userdefined> dbg]: ddns_verify_complete mit dns->handle 0x77443638
[2018-06-12 21:02:20 v4 <userdefined> dbg]: verify failed, is 87.144.156.229, but should be 87.144.157.177
[2018-06-12 21:02:20 v4 <userdefined> dbg]: verify failed: DNS reply: noerror -> retry verify in 240 secs
[2018-06-12 21:02:20 v6 <userdefined> dbg]: ddns_verify_complete mit dns->handle 0x77443a68
[2018-06-12 21:02:20 v6 <userdefined> dbg]: verify failed, is 2003:73:d7f:8326:zzzz:zzzz:zzzz:zzzz, but should be 2003:73:d7f:8f40:zzzz:zzzz:zzzz:zzzz
[2018-06-12 21:02:20 v6 <userdefined> dbg]: verify failed: DNS reply: noerror -> retry verify in 240 secs
[2018-06-12 21:06:20 v4 <userdefined> dbg]: dns_handle created 0x77443648 for 87.144.157.177
[2018-06-12 21:06:20 v4 <userdefined> dbg]: ddns_verify_complete mit dns->handle 0x77443648
[2018-06-12 21:06:20 v4 <userdefined> dbg]: verify failed, is 87.144.156.229, but should be 87.144.157.177
[2018-06-12 21:06:20 v4 <userdefined> dbg]: verify failed: DNS reply: noerror -> retry verify in 240 secs
[2018-06-12 21:06:20 v6 <userdefined> dbg]: dns_handle created 0x77443648 for 2003:73:d7f:8f40:zzzz:zzzz:zzzz:zzzz
[2018-06-12 21:06:20 v6 <userdefined> dbg]: ddns_verify_complete mit dns->handle 0x77443648
[2018-06-12 21:06:20 v6 <userdefined> dbg]: verify failed, is 2003:73:d7f:8326:zzzz:zzzz:zzzz:zzzz, but should be 2003:73:d7f:8f40:zzzz:zzzz:zzzz:zzzz
[2018-06-12 21:06:20 v6 <userdefined> dbg]: verify failed: DNS reply: noerror -> retry verify in 240 secs
[2018-06-12 21:10:20 v4 <userdefined> dbg]: dns_handle created 0x77443438 for 87.144.157.177
[2018-06-12 21:10:20 v6 <userdefined> dbg]: dns_handle created 0x77443008 for 2003:73:d7f:8f40:zzzz:zzzz:zzzz:zzzz
[2018-06-12 21:10:20 v4 <userdefined> dbg]: ddns_verify_complete mit dns->handle 0x77443438
[2018-06-12 21:10:20 v4 <userdefined> dbg]: verify failed, is 87.144.156.229, but should be 87.144.157.177
[2018-06-12 21:10:20 v4 <userdefined> dbg]: verify failed: DNS reply: noerror -> retry verify in 240 secs
[2018-06-12 21:10:20 v6 <userdefined> dbg]: ddns_verify_complete mit dns->handle 0x77443008
[2018-06-12 21:10:20 v6 <userdefined> dbg]: verify failed, is 2003:73:d7f:8326:zzzz:zzzz:zzzz:zzzz, but should be 2003:73:d7f:8f40:zzzz:zzzz:zzzz:zzzz
[2018-06-12 21:10:20 v6 <userdefined> dbg]: verify failed: DNS reply: noerror -> retry verify in 240 secs
[2018-06-12 21:14:20 v4 <userdefined> dbg]: dns_handle created 0x77443638 for 87.144.157.177
[2018-06-12 21:14:20 v6 <userdefined> dbg]: dns_handle created 0x77443818 for 2003:73:d7f:8f40:zzzz:zzzz:zzzz:zzzz
[2018-06-12 21:14:20 v4 <userdefined> dbg]: ddns_verify_complete mit dns->handle 0x77443638
[2018-06-12 21:14:20 v4 <userdefined> dbg]: verify failed, is 87.144.156.229, but should be 87.144.157.177
[2018-06-12 21:14:20 v4 <userdefined> dbg]: verify failed: DNS reply: noerror -> retry verify in 240 secs
[2018-06-12 21:14:20 v6 <userdefined> dbg]: ddns_verify_complete mit dns->handle 0x77443818
[2018-06-12 21:14:20 v6 <userdefined> dbg]: verify failed, is 2003:73:d7f:8326:zzzz:zzzz:zzzz:zzzz, but should be 2003:73:d7f:8f40:zzzz:zzzz:zzzz:zzzz
[2018-06-12 21:14:20 v6 <userdefined> dbg]: verify failed: DNS reply: noerror -> retry verify in 240 secs
[2018-06-12 21:18:20 v4 <userdefined> dbg]: dns_handle created 0x77443008 for 87.144.157.177
[2018-06-12 21:18:20 v6 <userdefined> dbg]: dns_handle created 0x77443648 for 2003:73:d7f:8f40:zzzz:zzzz:zzzz:zzzz
[2018-06-12 21:18:20 v4 <userdefined> dbg]: ddns_verify_complete mit dns->handle 0x77443008
[2018-06-12 21:18:20 v4 <userdefined> dbg]: verify failed, is 87.144.156.229, but should be 87.144.157.177
[2018-06-12 21:18:20 v4 <userdefined> dbg]: ep=0x7782da00 restart_verify_set_timer:1454 updated -> offline
[2018-06-12 21:18:20 v4 <userdefined> dbg]: verify failed: DNS reply: noerror.
[2018-06-12 21:18:20 v4 <userdefined> dbg]: ep=0x7782da00 reset_account:903 offline -> offline
[2018-06-12 21:18:20 v4 <userdefined> dbg]: Retry update in 300 secs.
[2018-06-12 21:18:20 v6 <userdefined> dbg]: ddns_verify_complete mit dns->handle 0x77443648
[2018-06-12 21:18:20 v6 <userdefined> dbg]: verify failed, is 2003:73:d7f:8326:zzzz:zzzz:zzzz:zzzz, but should be 2003:73:d7f:8f40:zzzz:zzzz:zzzz:zzzz
[2018-06-12 21:18:20 v6 <userdefined> dbg]: ep=0x7782dc00 restart_verify_set_timer:1454 updated -> offline
[2018-06-12 21:18:20 v6 <userdefined> dbg]: verify failed: DNS reply: noerror.
[2018-06-12 21:18:20 v6 <userdefined> dbg]: ep=0x7782dc00 reset_account:903 offline -> offline
[2018-06-12 21:18:20 v6 <userdefined> dbg]: Retry update in 300 secs.
[2018-06-12 21:23:20 v4 <userdefined> dbg]: ddns_update: offline (87.144.157.177)
[2018-06-12 21:23:20 v4 <userdefined> dbg]: ep=0x7782da00 ddns_update:3377 offline -> checking
[2018-06-12 21:23:20 v6 <userdefined> dbg]: ddns_update: offline (2003:73:d7f:8f40:zzzz:zzzz:zzzz:zzzz)
[2018-06-12 21:23:20 v6 <userdefined> dbg]: ep=0x7782dc00 ddns_update:3407 offline -> checking
[2018-06-12 21:23:20 v4 <userdefined> dbg]: new address
[2018-06-12 21:23:20 v4 <userdefined> dbg]: starting update (new address) [update_v6_addr 0] {87.144.157.177}
[2018-06-12 21:23:20 v4 <userdefined> dbg]: ep=0x7782da00 do_connect:2267 checking -> updating
[2018-06-12 21:23:20 v6 <userdefined> dbg]: new address
[2018-06-12 21:23:20 v6 <userdefined> dbg]: starting update (new address) [update_v6_addr 1] {2003:73:d7f:8f40:zzzz:zzzz:zzzz:zzzz}
[2018-06-12 21:23:20 v6 <userdefined> dbg]: ep=0x7782dc00 do_connect:2267 checking -> updating
[2018-06-12 21:23:21 v4 <userdefined> out]:
SSL
GET /nic/update?hostname=mydns.spdns.de&myip=87.144.157.177 HTTP/1.1
Host: update.spdyn.de
Authorization: Basic YzEyNjgzzzzmJpdzzzzQ==
User-Agent: Fritz!Box DDNS/1.0.1
Connection: close

Die Fehler entstehen beim Vergleich der IP-Adressen.

Den Dyndns-Dienst habe ich übrigens seit gestern ca: 21:30Uhr in der Fritz!Box deaktiviert.

 

[Micha0815]

Ich konnte bei Secure Point auf diversen Hosts hier und in AT ein ähnliches Verhalten wie in #929 @Pom-Fritz! feststellen seit gestern Abend. Bevorzugt auf ">name<.spdns.de" und einem Resync. >name<.spdns.eu war wohl nicht betroffen.
Da auch VPN-Initiator-Boxen (hier UMTS) den Host nicht fanden, schien es wohl ein Problem bei Secure-Point gewesen zu sein.
LG
P.S.: Hier zu den Warnungen lohnt sich auch ein Blick. Die Umbenennung update.spdns.de nach update.spdyn.de hatte auch eine recht lange Übergangsfrist. Im Rahmen von IPv4/IPv6 könnte ähnliches ablaufen (vgl. Link)

 

[Pom-Fritz!]

Danke für den Link "zu den Warnungen", aber das hatte ich schon lange vorher aktualisiert - siehe auch #929.

Hab den DynDNS-Dienst jetzt wieder aktiv. Mal sehen, ob's noch Warnungen gibt

Edit: Jetzt, nach 50 Minuten sind noch keine Warnungen aufgetaucht. Sieht also so aus, als hätte Secure Point gestern ein Problem gehabt und ich hab's auf die Firmware geschoben. Asche auf mein Haupt...

 

[PeterPawn]

Offenbar erfolgt da das Update beim Provider dann doch nicht (trotz passender Antwort, denn sowohl "good" als auch "nochg" (für "keine Änderung") sind ja positive Quittungen) oder irgendein DNS-Server in der Kette vom DynDNS-Provider bis zur FRITZ!Box bietet - unzulässigerweise - noch alte Daten an. Denn wenn die Box auf "...157.177" aktualisiert und bei der nachträglichen Kontrolle kommt dann doch die "...156.229" zurück, dann paßt das ja nicht zueinander und da ist es nachvollziehbar (bzw. extra so vorgesehen mit dieser (m.W. auch nicht deaktivierbaren) Überprüfung durch anschließende DNS-Abfrage), wenn die FRITZ!Box es immer wieder probiert.

Hier muß man also "an die Quelle" der DNS-Daten gehen (mit direkter Abfrage beim autorisierenden Name-Server) und überprüfen, ob der Server schon falsch antwortet oder ob auf dem Weg irgendein Cache falsche bzw. veraltete Daten ausliefert.

 

[HabNeFritzbox]

Und wo ist nun Zusammenhang mit dieser Firmware?

Zurück zum Thema.

 

[PeterPawn]

Und wo ist nun Zusammenhang mit dieser Firmware?

Der liegt zwar nicht direkt auf der Hand, kann aber auch erst ausgeschlossen werden, wenn dann feststeht, daß nicht die FRITZ!Box (mit dieser Version) durch ihren eigenen Cache daran Schuld trägt, wenn hier alte Daten beim DynDNS-Daemon der Box ankommen.

Ansonsten trennt das Zeug einfach ab und verschiebt es in einen eigenen Thread ... aber das Antworten zu "verbieten", nur weil die Frage und die Antwort nicht ganz zum Thema des Threads passen, bringt niemanden wirklich weiter - die Frage bleibt dann "offen" genauso stehen und kann von jedem mit demselben Problem gefunden und gelesen werden und mit ein wenig Pech, hängt sich dann der Nächste in sechs Wochen noch dran, weil er ansonsten nichts anderes zum Thema "DynDNS-Update bei Securepoint geht seit der ersten Juni-Woche nicht mehr wie erwartet" gefunden hat.

Jetzt davon auszugehen, daß die Leute, die mit ihrer Eingangsfrage vielleicht den Thread etwas ins Aus geschoben haben, nun ihrerseits noch einmal das Thema von alleine in einem neuen Thread eröffnen, dürfte auch einigermaßen realitätsfern sein und zusätzlich gegen die "keine Crossposts"-Regel verstoßen ... damit bleibt (anstelle der Ermahnung) für mich als logische Konsequenz das Abtrennen in einen eigenen Thread und das kann nun mal nur jemand machen, der auch die notwendigen Berechtigungen in Xenforo hat. Es ist ja nun nicht so, daß diese Diskussion so überhaupt gar keinen Zusammenhang zu den ansonsten in diesem Board (und sogar in diesem Unterforum) ventilierten Themen hat.

 

[IngoKlein]

06.98-56990 Inhaus verfügbar

 

[Benares]

Am meisten nervt mich immer noch die fehlerhafte Anzeige der Hostnamen auf IP-Clients und Repeatern. Ansonsten aber läuft eigentlich alles recht gut.
Aber ob diese Beta/Inhaus schon das Zeug zu einer 7er hat, da hab ich meine Zweifel. Mal sehen.