Sammelthema für FB 7590 mit Firmware "Intern"/"Inhaus" bis 07.22

[PeterPawn]

@DickS:
Schalte mal die Verschlüsselung für den Gastzugang ein (und natürlich den Gastzugang selbst auch) ... dann sollte zumindest der Fehler (ReferenceError) in "displayEncryption" nicht mehr auftauchen.

Welche Auswirkungen dieser JS-Fehler am Ende hat, hängt auch von der Engine des Browsers ab. Wenn die einfach die Exception irgendwo abfängt und trotzdem weiter rendert (oder alten Inhalt im DOM hält und den rendert), dann sieht man halt trotz des Fehlers noch etwas ... aber der Fehler sollte trotzdem auftreten, denn da ist keine Browser-Weiche zu sehen im Code.

 

[DickS]

Verschlüsselung eingeschaltet: Seite wird einwandfrei dargestellt.

Ergo: Fehlerquelle gefunden

 

[PeterPawn]

Wenn das bei all denen, die von dem Problem mit der Anzeige berichteten, an demselben Fehler liegen sollte, lohnt sich ja vielleicht tatsächlich noch einmal eine etwas gründlichere Untersuchung der Isolation des Gastnetzes ggü. dem LAN bzw. WAN (bzw. der Filterung) - ich hätte gar nicht gedacht (unabhängig vom Wegfall der Störerhaftung und den neuen gesetzlichen Regelungen zum WLAN), daß so viele Leute tatsächlich offene Netze betreiben, zumal man das ja explizit einstellen muß.

Gerade mit Labor-Firmware finde ich das aber auch ziemlich leichtsinnig ... AVM übernimmt garantiert nicht die Verantwortung, wenn ein Fehler in einer Labor-Version zur Kompromittierung der FRITZ!Box oder des eigenen LANs führt, weil die Isolation gerade mal nicht richtig funktioniert(e). Es ist zwar gerade der Sinn von Labor-Reihen, solche Probleme aufzudecken ... aber dann schaltet man das (m.E.) gezielt für den Test entsprechend um und hinterher wieder zurück, denn daß AVM selbst offenbar gar nicht mit "offenem WLAN" testet, sieht man schon daran, daß dieses Problem überhaupt existiert, weil der falsche Name in "displaxEncryption()" sowohl beim Aufruf aus "getWlanAccessTable()" als auch aus "getGuestAccessTable()" zu denselben Ergebnissen führen sollte - das ist also nicht nur auf das Gastnetz beschränkt.

 

[tester25]

Funktioniert die Indexierung externer Speicher des Mediaservers wieder in der neuen Inhouse? Das wäre für mich ein guter Grund, von der Labor auf diesen Channel zu switchen.

 

[flak65]

Bei mir kommt: Das Update ist fehlgeschlagen. Die angegebene Datei enthält kein von AVM für dieses Gerät freigegebenes Fritz!OS.

Hab eine 1und1 7590 mit Labor-Firmware. Kann ich von dieser nicht upgraden?

 

[Blackace]

Am besten lädst das Image nochmal neu runter, hört sich eher nach einem kaputten Image an.

 

[flak65]

über meine linux vm ging es. heruntergeladen mit dem wget und über firefox installiert. über windows und firefox ging es nicht.

 

[tester25]

Tauchen bei euch auch dubiose Netzwerkgeräte in der Offline-Liste auf?
Die lassen sich auch nicht löschen; die benannten und aktiven Geräte sind aber korrekt aufgelistet.

 

[Robert T-Online]

Nein die tauchen hier nicht auf.
Nur die altbekannten Darstellungsfehler in der Heimnetzübersicht schleichen sich nach kurzer Zeit immer noch ein obwohl nach dem Reboot alles korrekt angezeigt wird.

 

[SnoopyDog]

über windows und firefox ging es nicht.

Das Problem habe ich seit den neuesten Firefox-Versionen auch. Die LED an der Fritz!box fängt an zu blinken - d.h. die Box erwartet Daten - aber der Upload wird nicht ausgeführt. Wenn ich dann zum IE wechsle und das Update erneut starte, klappt es.

 

[PeterPawn]

Die LED an der Fritz!box fängt an zu blinken - d.h. die Box erwartet Daten - aber der Upload wird nicht ausgeführt.

Das Blinken hat damit nicht wirklich zu tun ... die Box sollte (zumindest bis zur 06.92) erst dann mit dem Update überhaupt beginnen (welche LED da genau warum blinkt, ist ja dann die nächste Frage - das Update selbst sorgt nur für das Blinken der INFO-LED), wenn die Übertragung vom Browser bereits abgeschlossen ist und die Update-Vorbereitungen schon laufen, weil die Firmware schon als gültig akzeptiert wurde. Das dauert heutzutage ggf. alles etwas länger mit dem Start des eigentlichen Updates, wenn die Box vorher noch jede Menge Mails versenden will (Info, Einstellungen, usw.).

Wahrscheinlicher ist hier (für mich zumindest) die Vermutung, daß ein Online-Speicher in der Box eingerichtet ist - in diesem Zusammenhang kann es (durch zweimaliges Stoppen des WebDAV-Services, 1x weil der USB-Stack und damit der Zwischenspeicher verloren geht und 1x, weil das "davfs2" nicht schnell genug beendet wird und noch einmal gestoppt werden soll) zu einer "race condition" (in genau diesem "prepare_fwupgrade") kommen, die dann in der Box von einem 120-sekündigen Warten bis zum kompletten Hängen (aber selten) alles auslösen kann - ist hier auch ab und an mal als Problem zu lesen, daß ein reiner Neustart der Box eine gefühlte Ewigkeit dauert.

Ich würde also eher darauf tippen, daß es nach einiger Wartezeit (die kommt einem halt unendlich lang vor, wenn man zuschaut und das nicht gewohnt ist bzw. es erwartet) von alleine weitergeht oder - sollte wirklich ein Timeout für den HTTP-Request auftreten - es auch mit demselben Browser bei einer Wiederholung klappt (weil der USB-Stack halt schon abgeräumt ist und auch der WebDAV-Service irgendwann mal endet).

Wer solchen (wiederholten bis ständigen) Problemen aus dem Weg gehen will (zumindest bis zur 06.92, ob AVM das auch korrigiert hat im Labor, weiß ich noch gar nicht), kann auch zuvor schon den Online-Speicher aushängen lassen, entweder über die Checkbox oder auch über das Auswerfen des Sticks für den Cache - vielleicht hilft das ja bereits.

Das ist zwar auch nur "Beobachtung" (auf /dev/console) und eine mögliche Erklärung, aber sie ist wahrscheinlicher als die Vermutung, bei einem HTTP-Upload (wo ja kein JS im Browser mehr eine Rolle spielt oder ähnliches) würde die Version des Browsers oder dessen "Ursprung" (aka Engine) einen Unterschied machen (solange der nicht selbst eine Beta-Version mit Fehlern ist) - es ist auch der Server, der am Ende entscheidet, wann er mit dem Start des CGI-Binary (das ist hier "firmwarecfg") beginnt und der Browser hat da (fast) keinen Einfluß (höchstens bei verschiedenen HTTP-Protokoll-Versionen mit oder ohne "keep alive" für die Verbindung).

 

[fritzfon9]

Habe das jetzt eine Weile beobachtet. Wenn ich morgens den PC starte dauert es im Vergleich zu allen anderen FW. ziemlich lange bis in der Taskleiste das gelbe 3ECK Internet verschwindet.

Internet ist mit Lan1 zum PC verbunden und nicht momentan mit Repeater

Oft 1 1/2 Minuten. Es gibt keine Fehlermeldung. Vielleicht hat auch schon jemand die Verzögerung FB7590-6.98-49090Inhouse bemerkt.

Nachtrag.

Da sich bisher keiner gemeldet hat, kann man meine Anfrage ignorieren. Die FW läuft ansonsten so gut und Fehlerfrei, das ich glaube mit einer der neuen FW die Kleinigkeit behoben wird.

 

[Kat-CeDe]

Hi,
benutzt jemand die HABridge um mittels einer fritz.php die Dect-Steckdosen zu schalten? Ich benutze es eigentlich recht erfolgreich seit 10 Tagen aber jetzt mit der neuen internen Version (ich meine damit fing es an) gibt es Probleme mit der Anmeldung. Im Log sehe ich immer:
"Anmeldung des Benutzers [Benutzername] an der FRITZ!Box Benutzeroberfläche von IP-Adresse [IP-Adresse] gescheitert (falsches Kennwort)."
und zwar unabhängig davon ob das Schalten klappt oder nicht. Also auch wenn geschaltet wird gibt es diesen Eintrag. Dann gibt es noch den Fall das 403 geliefert wird und dann plappert Echo seine geliebte Fehlermeldung das ein Gerät nicht funktioniert. Im Moment ist es geht, geht nicht, geht, geht, geht nicht, geht nicht und das ist nicht so schön. Hat sich beim Login was geändert?

Wenn ich es richtig verstehe ist das die Problemstelle ich weiß aber nicht warum.

$ch = curl_init('http://192.168.178.1/login_sid.lua?username=' . $fritzbox_User);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$login = curl_exec($ch);
$session_status_simplexml = simplexml_load_string($login);

if ($session_status_simplexml->SID != '0000000000000000')
{
        echo "Already logged on with SID " . $SID . "\n" ;
   $SID = $session_status_simplexml->SID;
}
else
// Calculate Session ID with Challenge, Password and MD5-Encoding
{
   $challenge = $session_status_simplexml->Challenge;
   $response = $challenge . '-' . md5(mb_convert_encoding($challenge . '-' . $fritzbox_Password, "UCS-2LE", "UTF-8"));
   curl_setopt($ch, CURLOPT_POSTFIELDS, "response={$response}&page=/login_sid.lua");
   $sendlogin = curl_exec($ch);
   $session_status_simplexml = simplexml_load_string($sendlogin);
   if ($session_status_simplexml->SID != '0000000000000000'){
       $SID = $session_status_simplexml->SID;
   }
   else{
       //echo "Error: Cannot connect to Fritz!Box";
       http_response_code(403);
       return;
   }
      
}

Ralf

 

[SnoopyDog]

Ich würde also eher darauf tippen, daß es nach einiger Wartezeit (die kommt einem halt unendlich lang vor, wenn man zuschaut und das nicht gewohnt ist bzw. es erwartet) von alleine weitergeht

Nein, tut es leider nicht. Wie schon gesagt klappt das Update mit den neuen Firefox-Versionen bei mir nicht mehr. Ich verwende hierzu deshalb nur noch den IE.

 

[Kat-CeDe]

Hi,
was heißt neuen Firefox-Versionen? Ich habe die letzte Version mit Firefox unter Linux aktualisiert.

Ralf

 

[Mordrag]

Ich aktuallisiere mit dem Nightly und das klappt auch ihne Probleme!

 

[DickS]

Gibt 4.02 für FritzFons

Version 4.02
· Behoben: Keine Funkverbindung nach aktiven DECT-Eco(No-Emission)
· Behoben: Fehlerhafte Feldstärkeanzeige
· Behoben: Uhrzeit im Startbildschirm u.U. nicht korrekt

 

[juf]

@fritzfon9
Ich kann dir zustimmen, mit der 48629 habe ich mit meinem PC an LAN1 auch.

 

[fritzfon9]

Danke juf für die Info.

 

[fritzfon9]

DickS alle 3 C4 habe ich ein Update gemacht und alles ist wie du beschrieben.

Bitte Beitrag nach Firmware 4.0x ab 6.98-484xx verschieben. Danke.