[Frage] FitzBox 6490 Kdg 6.50

error_403 schrieb:

[...] bezweifle das irgendjemand derzeit auf eine 6.83 updaten kann über das Auto Update.

Zum Vergrößern anklicken....

Stimmt auffallend ... der AVM-JUIS stellt im Moment keine Update-Information für 06.83 bereit bei der 6490. Wer weiß, was da wieder los ist ... hier rächt es sich wieder bitter, daß es seitens AVM keine ordentlichen Informationen zu diesen Update-Ständen gibt.

Man kann nur jedem Kunden mit 06.63 (Retail) die Empfehlung geben, bei AVM im Support aufzuschlagen und unter Verweis auf die bekannten Sicherheitsprobleme bis einschließlich 06.63 nach der neuen Version zu fragen. Selbst wenn die wieder andere und ggf. sogar neue Probleme haben sollte (wenn es welche sind, die den Betrieb der Box mit dieser Version verhindern, dann müssen eben auch da die Karten auf den Tisch gelegt werden - wobei das so schlimm nicht sein kann, bei mir läuft sie in großen Teilen stabil), so beseitigt sie doch ältere.

Ich will jetzt auch nicht gleich den Aluhut aufsetzen ... das einzige Problem, was ich (seit heute morgen erst) habe, ist die Unmöglichkeit einer TLS-Verbindung mit www.heise.de über die 6490 am VF/KD-Anschluß, während es über die Telekom und/oder über einen VPN-Tunnel mit einem Dedicated-Server als Endpunkt problemlos funktioniert. Das würde ich jetzt nicht gleich in der Firmware der Box suchen, sondern eher im Netz des Providers ... ein paar andere Services wie GitHub oder freetz.org haben ebenfalls leichte Probleme, aber bei www.heise.de sind die stabil und reproduzierbar und es ist auch mehr als ein AS betroffen.

Da man ja bei den Ursachen für dieses "Zurückziehen" der 06.83 (wieder einmal) nur raten kann, läge natürlich ein Zusammenhang zwischen dem DS-Lite-Problem (bei UM kommt wohl auch bei Kundengeräten DS-Lite zum Einsatz) und dem Zurückstellen der 06.83 nahe ... da es keine (offizielle) Möglichkeit zum Downgrade und auch kein Recovery-Programm gibt, funktioniert dann wohl die 6490 an UM-Anschlüssen nicht mehr richtig mit der 06.83 - sofern die Berichte zu diesem DS-Lite-Problem stimmen. Ich warte ja mal gespannt, wann/ob es von AVM (vom Support) einen Hinweis auf die Download-URL für die 06.83 gibt - offiziell existiert die ja gar nicht. Aber die 06.63 läßt sich eben auch "aus dem Netz schießen" - hier hat man also nur die Wahl zwischen Pest und Cholera und - wenn das DS-Lite-Problem das einzige sein sollte - an "nicht DS-Lite"-Anschlüssen sollte man dann ja trotzdem auf die 06.83 setzen.

Das wäre dann ja auch erst recht ein Grund, warum es zeitnah eine "Nachfolge-Version" geben müßte - aber auch hier ist es wie immer: Keine belastbaren Informationen und damit schießen (natürlich) die Spekulationen ins Kraut. Eine Information (gesetzt den Fall, das vermutete Problem stimmt) der Art: "Mit der 06.83 gibt es ein Problem an DS-Lite-Anschlüssen, wir werden innerhalb der nächsten 7 Tage eine korrigierte Version bereitstellen." wäre ja nun auch "kein Beinbruch" ... aber es kratzt natürlich am Nimbus (den aber m.E. ohnehin niemand ernstnehmen kann).

Beispiel-Link: https://www.unitymediaforum.de/viewtopic.php?t=34928&start=100#p375127

Vielleicht erklärt das auch, warum mein Ticket zu den GPL Sourcen der 06.83 schon seit 3 Wochen offen ist.

@PeterPawn

Nochmal kurz zu dem VOIP Interface, ich würde fast behaupten, dass alle großen Anbieter dieses per ACS anlegen und nicht über den weg des "MTA" Files machen.
Weil im Modem Configfile ist dies nicht möglich, wenn müsste man Packetcable provisionieren und irgendwie bezweifle ich das. Die Classifier für VOIP ist ja eine ganz andere Sache, die stehen natürlich im Modem Configfile.
Klar es geht auch so würde aber wirklich bei einer Fritzbox wenig Sinn manchen, zumal alle Anbieter soweit ich weiß denselben ACS einsetzen.

Wenn man das nicht per TR-069 macht, braucht man diesen ja praktisch nicht, weil dann alle Daten in dem entsprechenden File liegen. Kleine Anbieter klar die werden diesen Weg gehen.
Ok DVB-C sperren und VOIP GUI read-only, aber wenn macht man doch gleich alles per TR-069.

@error_403:
Noch mal deutlich ... ich weiß es auch nicht definitiv, wie das heutzutage (bei VF/KD konkret) läuft; weder bei der SIP-Konfiguration noch bei den "features" (wobei die vermutlich gar nicht konfiguriert werden und auf "Standard" bleiben).

Ich weiß nur, daß es (der Ansicht im Code der Firmware nach zumindest) die Möglichkeiten gibt, das auch über SNMP beides zu konfigurieren ... ja, für die "feature configuration" (z.B. 0x10 für "CONFIG_LINEARTV=y") gibt es m.W. nicht einmal eine Alternative per TR-069 - aber ich weiß auch nicht, welche TLV-"Nummer" von AVM dafür vorgesehen wurde. Gut möglich, daß das nicht einmal in der Beschreibung für die "anderen" Provider auftaucht, denn das ist ja nur bei Branding "kdg" oder "lgi" deaktiviert und es gibt über SNMP auch nur die Möglichkeit, das zu aktivieren.

Die von AVM da in der Retail-Firmware hinzugebaute Sperre (da wird bei Branding "avm" das "docsis_feature_disable" komplett übergangen) soll wohl nur verhindern, daß da der Provider versehentlich durch Setzen der entsprechenden TLV (ich kann mich immer nicht mit mir einigen, welches grammatikalische Geschlecht "tag/type - length - value" nun im Deutschen haben sollte) irgendwelche Änderungen an der Konfiguration von Kundenboxen vornimmt.

Solange hier kein Admin von VF/KD aufschlägt, der dazu Auskunft geben kann, wie bei VF/KD nun die Telefonie konfiguriert wird, müßte sich halt ein VF/KD-Kunde mit einer Provider-Box finden, der nach/bei einer Neukonfiguration durch den Provider mal in die Support-Daten schaut. Ich habe zwar den VF/KD-Anschluß, aber keine 6490 vom Provider und damit konfiguriert der mir da auch für Geld und gute Worte keine Telefonie drauf ... damit kann ich das einfach nicht testen.

Das Argument, daß man ansonsten PacketCable konfigurieren müßte, kann ich nicht so richtig nachvollziehen ... nach meinem Verständnis muß man das doch für alle (eigenen) CMs mit EPC 1.5 auch machen oder lassen sich bei anderen Geräten die MGCP-Settings tatsächlich per TR-069 übermitteln? Wenn nicht, ist das doch aber (außer der Version und ggf. anderen Settings für RST) genau dasselbe, was für alle anderen Geräte auch passieren muß?

Wie gesagt, zumindest ist eine SIP-Konfiguration über SNMP vorgesehen, wie man mit einem Blick in die Zeichenketten in der "pacm_snmp_agent" leicht feststellen kann. Da sind praktisch alle notwendigen Versatzstücke vorhanden, um ein Lua-File zu generieren, das dann wieder die Daten für eine "Eigene Rufnummer" über die luavar-Schnittstelle direkt einträgt. Ob das von VF/KD heutzutage noch genutzt wird, weiß ich nicht ... ist aber leicht zu ermitteln, notfalls durch Ändern des ACS in den Einstellungen. Damit kann man dann auch gleich überprüfen, ob der ACS bei VF/KD beim Provisionieren neu gesetzt wird. Wenn dann trotzdem falschem ACS SIP-Accounts angelegt werden, kommen die eben nicht vom ACS.

Aber mehr als einen Weg zum Test vorschlagen, kann ich derzeit auch nicht ... ich habe mal einen Suchlauf nach einer früheren "snmp_sip.lua" über meine Archive angeworfen. Als Dateiname taucht der schon mal nicht direkt auf, aber das kann auch gut innerhalb einer komprimierten Datei sein und so dauert die Suche wohl noch 1-2 Tage, zumal ich der auch nur geringe Priorität eingeräumt habe (sie hat in 135 Minuten immerhin schon 3% der Daten durchsucht).