[Info] Fritzbox 7490 Firmware Version 6.23 (vom 17.12.2014)

[Kaffeejunkie]

c9 und c16 wird der port des Patchfeldes C sein. Somit gehe ich von aus, dass technicalProNo nen größeres Netzwerk hat.

 

[HabNeFritzbox]

Frag mich auch, was es mit dem Problem zutun hat. Habe bisher nichts davon gelesen, dass anderen nen 16 Port Switch haben, und durch umstecken am Switch die FB wieder ohne Probleme arbeitet.

Und vor alldem welcher LAN Port oder welches Netzkabel auf 5GHz im WLAN arbeitet.

 

[SaschaBr]

Was c9 und c16 heißt, kann ich mir schon denken (Link), kann aber eben keinen Zusammenhang zu den WLAN-Problemen sehen.

 

[HabNeFritzbox]

Laut dem Thema http://www.ip-phone-forum.de/showthread.php?t=275965 kann bei WLAN Problem USB 3 Schuld sein bzw das USB Gerät. Wenn zutrifft mal USB 2 verwenden oder Stick entfernen.

 

[rkf]

... kann bei WLAN Problem USB 3 Schuld sein bzw das USB Gerät. ...

Leider nur kann. Habe bei mir gar nichts an USB angeschlossen und USB 2 konfiguriert - und habe dennoch die Probleme.

Gruß Ralf.

 

[tester25]

Laut dem Thema http://www.ip-phone-forum.de/showthread.php?t=275965 kann bei WLAN Problem USB 3 Schuld sein bzw das USB Gerät. Wenn zutrifft mal USB 2 verwenden oder Stick entfernen.

Auch bei mir ist nur eine USB 2.0 Festplatte angeschlossen, die Box zudem an beiden Anschlüssen auf USB 2.0 gedrosselt.

 

[marmor3]

Zu dem Problem das ich wenn ich eine jpg Datei faxen wollte und zusätzlich bei der Texteingabe beim Faxversand einen Fehler erhielt:

Gibt es evt nur mit dem Text ein Problem?

Evt. wurden ja noch Steuerzeichen, Tabs oder ähnliches mit kopiert, was zu einem Fehler führt.

Eigentlich nicht. Es war nur ein kurzer Text den ich die vier Versuche jedes mal eintippte. So zirka: Wie telefonisch besprochen das Fax, ich bitte um Erledigung. Mit freundlichen Grüßen .....

die Größe der jpg Datei, die ich ohne Text, alleine versenden konnte betrug 1373 kb

Also hatte noch niemand diesen Fehler?

 

[marmor3]

Leider nur kann. Habe bei mir gar nichts an USB angeschlossen und USB 2 konfiguriert - und habe dennoch die Probleme.

Gruß Ralf.

Bei mir ebenfalls, nur ich verwende WLAN so gut wie nie, insofern stört mich das Problem nicht sonderlich. Ich habe im ganzen Haus vor knapp 15 Jahren lankabel verlegen lassen

 

[Dann halt nicht mehr]

Die Hardware-Revision 5 hat eine geänderte WLAN-Antenne. Es ist - so wie bei der 7390 auch - nun ein Paddel verbaut, dass zwei Zuleitungen hat. Im Vergleich zur Hardware-Version 3 ist dieses Paddel nicht vorhanden gewesen, sondern lediglich etwas, das ins Gehäuse geklebt wurde (etwa auf der Höhe des USB-Seitenausgangs.

 

[neutron666]

Bei mir ebenfalls, nur ich verwende WLAN so gut wie nie, insofern stört mich das Problem nicht sonderlich. Ich habe im ganzen Haus vor knapp 15 Jahren lankabel verlegen lassen

Das nutzt meinem Smartphone und Tablet aber nix..

 

[mac_phone]

Verbindungsneuaufbau bei Betätigung WLAN-Taster

Hi,

Anfang November schrieb ich im Thread der Firmware-Version 6.20 über einen regelmäßig bzw. sogar jedesmal wiederkehrenden Neustart der FB nach Betätigung des WLAN-Tasters:
Klick!

Damals half nur eine Rückkehr zur vorherigen 6.03:
Klick!

Weitergehende Infos über den Neustart konnte ich mit der 6.20 dem Log der FB nicht entnehmen, da in dort (vermutlich durch den Reset) immer gähnende Leere herrschte, sobald die Box wieder erreichbar war. Meine Hoffnung bestand darin, daß sich das Problem mit der nächsten Version in Luft auflösen würde. Von daher hab ich jetzt auch die 6.23 drauf gespielt. Nur ist das Verhalten nachwievor das gleiche. Jetzt startet die FB zwar nicht komplett neu, die Verbindung wird aber trotzdem kurzzeitig getrennt und neu aufgebaut. Damit gehen in diesem Moment natürlich auch alle Internetverbindungen sowie die Telefongespräche flöten. Und - dieses Verhalten zeigt die FB nun auch beim AUSschalten des WLANs über den Taster, nicht mehr nur beim EINschalten - so wie es vorher bei der 6.20 nach meiner Erinnerung war, obwohl ich dafür jetzt gerade keine Garantie abgeben würde (ist mir für die 6.23 nur gerade sehr präsent, da mein Telefongespräch genau in dem Moment unterbrochen wurde, siehe unten!).

Mit der 6.23 kann ich jetzt allerdings mehr im Log sehen, da die Box mit dieser Firmware-Version halt nicht komplett neu startet, sondern nur die Verbindung zurücksetzt. Das hier steht im fraglichen Moment im Log:

08.01.15 22:43:37 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: ...
08.01.15 22:43:28 DSL ist verfügbar (DSL-Synchronisierung besteht mit 51390/10047 kbit/s).
08.01.15 22:43:03 Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.178.20.
08.01.15 22:41:54 Zeitüberschreitung bei der PPP-Aushandlung.
08.01.15 22:41:54 Internetverbindung wurde getrennt.
08.01.15 22:41:50 Internettelefonie mit 0... war nicht erfolgreich. Ursache: (555)
08.01.15 22:41:49 DSL antwortet nicht (Keine DSL-Synchronisierung).
08.01.15 22:41:46 WLAN wurde über den WLAN-Taster deaktiviert (2,4 + 5 GHz).

Ich hab die FB mit der 6.23 heute nun auch schon auf Werkseinstellungen zurückgesetzt und alle Einstellungen erneut von Hand vorgenommen - nachdem das Einspielen einer zuvor vorgenommenen Sicherungsdatei keine Veränderung brachte. Aber auch das Neuaufsetzen der Konfiguration hilft nicht.

Ich überlege jetzt schon, die Fritzbox evtl. auf Garantie umzutauschen. Denn es verwundert ja schon, daß außer mir niemand dieses Problem zu haben scheint. Oder bin ich evtl. kein Einzelschicksal mehr?

Grüße,
Mac

PS: Gerade nochmal verifiziert. Weder über Telefon noch über die Web-GUI tritt der Verbindungsabbruch beim Einschalten des WLANs auf. Bei Benutzung des WLAN-Tasters auf der Oberseite der Box passiert's "zuverlässig" jeweils beide Male bei An- sowie Abschalten.

 

[Hans Juergen]

Schalte die Tastenfunktionen ab...
Frage, wie sehr drückst du die Taste? Es geht ein Hebel auf die Platine, es wäre ein Fehler durch Biegung denkbar. Tritt der Fehler auch bei Bewegung der FB ohne direkte Tastenbewegung auf? Oder wenn die Tastenfunktion im WEB-IF abgeschaltet ist und die Taste dann gedrückt wird?
Einen Versuch gibts noch: Ein Recover und dann nur die Tastenfunktionen testen, ist das Phänomen dann noch da den AVM-Service einschalten.

 

[PeterPawn]

Frage, wie sehr drückst du die Taste?

Die Frage hat mich auch schon bewegt und ich habe mich trotzdem nicht getraut, sie zu stellen.

Denn im Ergebnis hieße das eigentlich auch, daß mac_phone bei der 06.03 immer weniger heftig auf den Knopf drückt, so daß ein Haarriß im PCB (das wäre bei mechanischer Belastung eine Erklärung für mich) sich da dann nicht auswirkt.

Ich habe mir vorhin sogar mal den Spaß gemacht und die Quellen für die Abfrage des Button-Zustands (ist ein GPIO-Pin, an dem der Taster hängt) für die 06.20 und die 06.01 (die 03 hatte keine eigenen Quellen, war nur der Fix für die webcm-Lücke) verglichen. Da habe ich keinen wesentlichen Unterschied in der Auswertung der Zustände gesehen, es müßte also wirklich auf unterschiedlich starken Druck auf den Taster - in Abhängigkeit von der Firmware-Version - hinauslaufen, wenn das nicht am Ende im WLAN-Code irgendwo liegt (sind ja sicherlich doch unterschiedliche Code-Zweige bzw. unterschiedliche Variablen, der WLAN-Treiber fragt den Taster ja nicht selbst ab).

 

[mac_phone]

Danke für die Antworten.

Also ich kann versichern, daß ich den Taster nicht anders drücke als zuvor bei der 6.03. Und eigentlich kann ich seit heute morgen speziell den mechanischen Taster als Fehlerquelle auch ausschließen. Anders als ich gestern Abend noch beobachten konnte, brach die Verbindung heute morgen(!) mit den gleichen Logprints auch nach Verwendung des Telefons (#96*1*) beim Anschalten des WLANs zusammen.
Ich werde nochmal probieren, ob das gleiche Verhalten auch direkt nach Zurücksetzen auf Werkseinstellungen auftritt. Dazu komme ich aber frühestens erst am Sonntagabend.

Grüße,
Mac

 

[Hans Juergen]

Sorry, das mit dem Rücksetzen auf die 6.03 hatte ich überlesen, sonst hätte ich das der Taste nicht geschrieben. Dabei noch einen mechanischen Fehler zu vermuten scheint mir doch etwas sehr weit hergeholt...
Dann fällt mir außer dem Recover-Vorschlag nichts mehr ein...

 

[mac_phone]

Der AVM-Support hat sich des Problems bereits angenommen. Dauert wahrscheinlich noch ein bißchen, bis sie sich zurückmelden.

Selbst wenn das Verhalten im Werkszustand nicht auftritt, sondern erst, wenn ich die Box wieder komplett konfiguriert habe, hilft mir das ja nicht viel weiter. Kann mir nicht vorstellen, daß die Ursache beim Internetanbieter und dessen Verbindungsparametern liegt. Hab von daher schon vorsorglich beim Händler nachgefragt, ob er das Teil auch ohne Quittung umtauscht (hab ich nämlich nicht mehr, lief ja auch ein Dreivierteljahr ohne Probleme bzw. läuft nachwievor mit der alten 6.03). Macht der Händler sogar. Dieses Mal hefte ich die Rechnung aber mit Sicherheit irgendwo ab.

Ich meld mich wieder, wenn AVM was zu erzählen hatte.

Grüße,
Mac

 

[eisbaerin]

Heute morgen (3:48 Uhr) das erste mal folgende E-mail erhalten:

Für Ihre FRITZ!Box 7490 ist ein neues FRITZ!OS 06.23 verfügbar.
Aktuell verwenden Sie die FRITZ!OS-Version 06.20.

Meine Frage ist jetzt:
Wieso gerade heute? Die FB läuft seit 7 Tagen ohne Änderung und auch davor lief sie schon ca. 2 Monate.
Hätte diese E-mail nicht schon am 17.12. kommen sollen?

 

[PeterPawn]

Hätte diese E-mail nicht schon am 17.12. kommen sollen?

Die Abfrage nach neuer Firmware erfolgt ohne Änderungen an der ar7.cfg nur im Wochenrhythmus (check_interval = 168; - das dürften Stunden (7 * 24) sein).

Mal wild spekuliert, sind nur Überlegungen, wie es sein könnte, nicht mißverstehen, daß es tatsächlich so sein muß/so ist:

Wenn die Update-Prüfung vor der Herstellung einer Internet-Verbindung gestartet wird (ich habe gerade auch nicht parat, wo der Anstoß dazu tatsächlich/vermutlich herkommt), dann kann der erste Versuch ja schon mal schiefgehen.

Je nachdem, was dann als "Ergebnis" daraus gemacht wird, könnte der Mechanismus bis zum nächsten Start komplett versagen oder - bei ungünstiger Berechnung des nächsten Zeitpunkts (die Einstellungen dafür stehen ja in der ar7.cfg) - ein Datum/eine Zeitspanne berechnet werden, die zu weit vom aktuellen Datum entfernt ist. Wenn da irgendwas mit kleiner als und größer als getestet wird zur Festlegung eines "Zeitraums" anstelle nur auf streng größer zu prüfen oder für die fehlgeschlagene Prüfung gar kein Datum gesetzt wird (dann wird mit hoher Wahrscheinlichkeit der 01.01.1970 daraus) und dieser Fall auch nicht richtig behandelt wird (so alt ist die automatische Update-Benachrichtigung ja auch noch nicht und das Auto-Update ist noch jünger) im laufenden Betrieb, dann könnte so etwas ja problemlos passieren.

Hast Du zufällig eine Sicherung von der Situation in der ar7.cfg vor dem Neustart vor 7 Tagen ? Wenn das tatsächlich ein Neustart war, das ist ja nur meine Interpretation der Geschehnisse vor 7 Tagen bei Dir. Auch die jetzt in der ar7.cfg vorhandenen Einstellungen (unattended_update) wären nicht uninteressant. Bei einer 7490 steht bei mir dort z.B. folgendes:

unattended_update {
        update_found = no;
        running_version = "";
        no_update_found_time = "2015-01-08 07:24:27";
        update_found_time = "1970-01-01 01:00:00";
        priority = 0;
        check_intervall = 168;
        status = 1002;
        StartTime = "2014-09-13 15:46:20";
        enabled = yes;
        auto_update_enable = no;
        auto_update_all_enabled = no;
}

Spannend finde ich vor allem den Eintrag "StartTime". Das ist das ungefähr 31 Tage nach dem Update der Box auf die 06.20-Release-Version (von Labor 06.10-28510), wie ich anhand der gesicherten Einstellungen per Push-Mail nachvollziehen kann. Ansonsten ist am 13.09. in den täglichen Push-Mails zu dieser Zeit absolut nichts zu sehen, die Box wurde am 13.09. um 12:02 Uhr mal neu gestartet, weil ich modfs auf einer "normalen" 7490 testen wollte. Stellt sich also am Ende die Frage, was soll das "StartTime" nun wirklich sein ? Zu dieser Zeit fand jedenfalls definitiv kein Offline-/Online-Wechsel der Box statt, also muß da noch ein anderer Trigger vorhanden sein.

Wieder lang und unnötig, aber ich mißbrauche das IPPF ja auch als persönliches Dokumentationssystem ... spart das Bloggen.

 

[eisbaerin]

erst sah die ar7.cfg so aus (nach Neustart am 6.1.2015):

unattended_update {
        update_found = no;
        running_version = "";
        no_update_found_time = "[COLOR="#FF0000"]2015-01-05[/COLOR] 18:09:55";
        update_found_time = "1970-01-01 01:00:00";
        priority = 0;
        check_intervall = 168;
        status = 0;
        StartTime = "1970-01-01 01:00:00";
        enabled = yes;
        auto_update_enable = yes;
        auto_update_all_enabled = no;
}

und seit heute so:

unattended_update {
        update_found = yes;
        running_version = "113.06.20";
        no_update_found_time = "1970-01-01 01:00:00";
        update_found_time = "2015-01-13 03:48:06";
        priority = 1;
        check_intervall = 168;
        status = 0;
        StartTime = "1970-01-01 01:00:00";
        enabled = yes;
        auto_update_enable = yes;
        auto_update_all_enabled = no;
}

Vor ca. 7 Tagen hatte ich den "halt" Befehl getestet und mußte dann ja Power off/on machen (6.1.2015 um 4:25).
Internet war über LAN1 sofort verfügbar.

Wieso wurde aber bei mir am 2015-01-05 und bei dir am 2015-01-08 kein Update gefunden?

 

[PeterPawn]

Wieso wurde aber bei mir am 2015-01-05 und bei dir am 2015-01-08 kein Update gefunden?

Tja, wenn ich das wüßte ... ich kann auch beim besten Willen keine Systematik sehen auf Anhieb.

Was mir auffällt ... bei Dir wird - trotz sofortiger Verfügbarkeit der WAN-Connection bei LAN1-Modus - die "no_update_found_time" auf "leer" bzw. "0" gesetzt (ist ja offenbar ein Timestamp-Wert). Das ist auch nicht etwa ein zeitlicher Unfall, weil da noch keine Uhrzeit gesetzt wurde von chrony oder so, wenn das so wäre, müßte die Uhrzeit ja wenigstens die beim Booten verstrichenen Sekunden anzeigen. Ob das direkt an das "update_found=yes;" gebunden ist ? Auch der priority-Wert wurde offenbar geändert, aber wofür wird das am Ende wohl gelten ?

Ich glaube irgendwie weiterhin, daß die Funktionen zum Update-Check und auch zum Auto-Update (das ja offenbar irgendwo in der Nähe des Update-Checks angesiedelt ist, wenn die Einstellungen dort untergebracht wurden in der ar7.cfg) einfach noch zu neu sind, um schon jeden möglichen Fall auch abzudecken. Da das m.W. nirgendwo in den Support-Daten protokolliert wird, was der Update-Check da "denkt", wird das wohl auch ohne Meldungen an AVM mehr darauf hinauslaufen, daß der Mechanismus "überwiegend funktioniert" und wenn von Auto-Updates - mal über den Daumen - 1 Prozent schief geht (immer noch eine große Zahl), dann macht wahrscheinlich der Schwund durch Fehler beim Update-Check auch den Kohl nicht fett, was den resultierenden Support-Aufwand aus der Kombination der beiden ergibt.

Die letzte Fehlerquelle, die mir dazu noch einfallen würde, wäre tatsächlich eine Fehlfunktion bzw. Überlastung / Wartung / was auch immer / des AVM-Update-Servers. Wenn man sich mal einen solchen Check mit einem Sniffer ansieht, ist das ja nicht das Ausliefern einer statischen Datei, sondern irgendein SOAP-Request, wenn ich das richtig in Erinnerung habe (so richtig was mit Challenge/Response für irgendwelche Authentifizierungen oder zur Sicherung der Angaben zum Update, denn das läuft ja über normales HTTP). Da wäre dann auch eine fehlende Antwort wegen ausgefallenem oder gewartetem Server eine denkbare Erklärung, der Update-Check ist sicherlich nicht "mission critical" und wird wohl kaum über irgendwelche Cluster realisiert (auch hier wieder nur begründete Annahmen, kein gesichertes Wissen).