FRITZ!Box 7590 FRITZ!OS 6.98-49475 BETA vom 12.01.2018

Mit der 06.98-49475 scheint im WLAN noch was zu klemmen.
Um bereits für das "Bandsteering" gerüstet zu sein, habe ich die vorher unterschiedlichen 2.4 und 5 GHz SSIDs zu einer gleichlautenden zusammengeführt.
Im Einsatz ist die 7590 vermesht mit einem 1750e (LAN-Brücke) und einem 546e (WLAN-Brücke).
Seitdem sind die beiden Galaxy S6 Geräte öfter mal offline und verbinden sich von selbst auch nicht mehr. Wann das passiert kann ich schwer sagen. Der Wechsel von 5 auf 2.4 GHz scheint zu klappen - wird zumindest im Log so eingetragen. Man muss dann am S6 WLAN aus- und wieder einschalten.
Hier hat der Support auch zur Verwendung von unterschiedlichen SSIDs geraten, obwohl ich der Meinung bin mit gleichlautender SSID sollte es auch funktionieren, zumal das ja mittlerweile auch Werksstandard ist bei den Boxen.

Nachtrag: Der entsprechende Logenintrag lautet dann: WLAN Anmeldung ist gescheitert (2,4GHz). Verbindungsaufbau fehlgeschlagen.
 
Zuletzt bearbeitet:
Gehen die internationalen auch für unsere Deutschen Boxen?
 
Gehen die internationalen auch für unsere Deutschen Boxen?
Scheinbar schon:
Die Datei heißt "FRITZ.Box_7590_LabBETA.en-de-es-it-fr-pl-nl.154.06.98-49686.image" und gilt wohl für mehrere Länder inklusive Deutschland wie man sehen kann. Dazu gibt es auch eine Recover Datei.

Gruß
Dietmar
 
Also auf meiner de.FB hat das nicht funktioniert, wurde beim Installationsversuch einfach abgewiesen.
 
Also auf meiner de.FB hat das nicht funktioniert, wurde beim Installationsversuch einfach abgewiesen.
Ich hatte es noch nicht probiert aber weil unter anderem dort "de" steht hatte ich angenommen, dass diese auch auf deutschen Boxen funktioniert.

Gruß
Dietmar
 
Das "de" im InternationalFWNamen steht einfach dafür, damit auch eine deutsche Übersetzung behinhaltet ist - ergo das GUI einem auf deutsch anspricht.

Das Problem wird eher "firmware_version avm" anstelle von "firmware_version avme" sein (Box im Bootloader abfangen, diese Env.variable ändern, Box weiter im Bootloader hängen lassen und das Recoverytool drüber laufen lassen

Wie @froeschi1962 gerade postete, funkioniert in dem Fall die Anleitung nur umgekehrt (also avm und avme)



//edit: handelt sich ja um die 7590... bei der 7490 gibt es ja diese und diese "Variante" - je nach Bootloader - sorry
 
Zuletzt bearbeitet:
Vielleicht funktioniert es so..
Bitte nicht zuhause nachmachen ... besser suchen und lesen, als nur zu raten.

Und bei der 7590 ist auch der Tipp von @stoney aus #70 wenig hilfreich ... selbst wenn das Recovery-Tool die Firmware dann tatsächlich installieren sollte (was es hoffentlich nicht tut), funktioniert diese schlichtweg nicht, wenn sie nach dem Booten dann wieder auf "avm" anstelle von "avme" trifft und dafür kein "Zweig" in der Firmware existiert. Die permanente Änderung der Environment-Variablen hat m.W. bei einer GRX5-Box noch keiner geschafft (ohne den Bootloader neu zu flashen, was auch nicht ganz ohne ist - der ist bekanntlich auch im NAND und liegt in mehreren Kopien vor, um gegen Flash-Fehler gewappnet zu sein).
 
Ja, die Verbindungen über den Repeater 1750E sind auch bei mir nach ein paar Stunden instabil. Aber auch über WLAN verbundene Gerät, wie z.B. eine Kamera melden mit der Labor-Fw des Routers immer wieder Unterbrüche.

Neben den WLAN-Problemen wird bei mir nach einer gewissen Zeit auch Heimnetzansicht nicht mehr aktualisiert. Dort erscheinen dann in der oberen Fenster-Hälfte Geräte, die gar nicht aktiv verbunden sind als verbunden.

Kann ich bestätigen.
 
@DSLAMist

Folgendes hat bei mir mit der aktuellen Labor 49475 zu stabilen WLAN-Verbindungen zwischen FB7590 und Repeater 1750E geführt. Hält jetzt über 24h stabil die Verbindung auf beiden Kanälen. EntertainTV ist ohne Unterbrechung und Aufhängen des MR401. Keine Resyncs bei DSL!

1. FB7590 mit Labor 49475 auf Werkseinstellungen zurückgesetzt und von Grund auf neu eingerichtet.
2. WLAN-Einstellungen: Funkkanal Einstellungen angepasst:
KEIN PMF und WLAN-Koexistenz deaktiviert und feste Kanäle für 2,4 und 5 GHz zugewiesen (Kanal 1 und Kanal 36)
3. Repeater 1750E mit Release-Fw. 6.93 auf Werkseinstellungen zurückgesetzt.
4. Mesh von der FB aus eingerichtet damit der Repeater die zuvor an der FB eingestellten Wert übernimmt

Weitere Defizite der Labor:
Nur ein Telefonbuch verfügbar
Diagnose/Sicherheit kann im IE nicht angezeigt werden (mit Firefox geht es)
 
@TSprecher

Danke für die Tipps.
Ich habe PMF mal ausgeschaltet. Das war noch aktiv.

Mal schauen ob es etwas bringt. Werkseinstellungen und händisch neuaufsetzen ist momentan nicht drin.

EDIT/Nachtrag: Auch mit ausgeschaltetem PMF kommt es immer wieder zu Verbindungsfehlern. Diesmal Authentifizierung fehlgeschlagen.
Hoffen wir, das es in der nächsten Version besser wird.
 
Zuletzt bearbeitet:
Ist euch schon mal aufgefallen, wenn man eine FritzBox 7590 als IP Client einrichtet, lässt sich der Zeitserver nicht mehr ändern!
Wenn man es als erstes ändert, nimmt er den den man Eingestellt hat, z.B. die Master FritzBox!

Oder ist die Einstelluing wo anders zu finden, als unter Heimnetz?
 
Ist ein Problem, das AVM schon seit Urzeiten mit sich herumschleppt - die Einstellungen für die Adresse des Uplink-NTP-Servers und die Einstellung, ob die Box selbst als NTP-Server auftreten soll, sind gemeinsam an "general.is_ip_client()" gekoppelt, obwohl sie nur sehr wenig miteinander zu tun haben.

Es fällt nur im Normalfall nicht weiter auf (eine Box als IP-Client, eine andere als Router, mit DHCP-Server und eingeschaltetem NTP-Server), weil die Box (als IP-Client) sich dann den NTP-Server aus der DHCP-Konfiguration holt und somit weiß, wo sie eine gültige Uhrzeit herbekommt.

Wer die Box als IP-Client betreibt und keinen NTP-Server per DHCP annonciert, kann es auch schon mal erleben, daß die Box (wegen eines ungültigen Eintrags für den NTP-Server ... nur wenn der komplett fehlt, wird wohl wieder auf einen Pool zurückgegriffen) gar keine Uhrzeit hat und auch in ihrem eigenen Event-Log eine Zeit vorgibt, bei der man auf die Suche nach dem "sonic screwdriver" gehen will, um die TARDIS zu reparieren, weil man irgendwie im falschen Film ist.

Aber da - wie gesagt - die Angabe in einem DHCP-OFFER ohnehin obsiegt (so habe ich das jedenfalls beim Testen festgestellt), stört es auch nicht wirklich, wenn man die Angabe im IP-Client nicht ändern kann. Notfalls geht's noch über die Export-Datei - oder über jeden Shell-Zugang, wenn man die Zugangsart nicht noch einmal umstellen will.

Eigene Änderungen ausschließlich am HTML-Code bzw. am HTTP-Request (über Developer-Tools im Browser) bringen jedenfalls nichts, weil das im Lua-Code noch einmal genauso abgefragt wird, wenn's ans Setzen neuer Werte geht.
 
Was aber total lustig ist, wenn man als 1. den Zeitserver ändert, dann die Box als IP Client einrichtet wird der Eingestellte Zeitserver beibehalten!
 
Ich bin mir zwar nicht 100% sicher, aber ich denke mal, daß der per DHCP-Option angesagte NTP-Server trotzdem vorgeht (wenn man DHCP für die Konfiguration der Box als IP-Client verwendet), auch wenn man einen eigenen eingestellt hat. Ist schon sehr lange her, daß ich das mal systematisch getestet hatte - vielleicht steht's hier sogar noch irgendwo in den Tiefen des IPPF.
 
Also, wenn man es erst Einstellt, dann als Client einrichtet, nutzer die Box den Zeit-Server den man Eingestellt hat:
"[AVM-Fritz-Box-7590] Die Systemzeit wurde erflogreich aktualisiert von Zeitserver 192.168.178.1"
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.