FRITZ!Box 7590 - Labor 154.07.08-64611 vom 11.01.2019

penum

Mitglied
Mitglied seit
11 Jan 2013
Beiträge
569
Punkte für Reaktionen
63
Punkte
28
Verbesserungen in FRITZ!OS 7.08-64611
Internet:
  • Verbesserung - Bei Freischaltung des HTTPS Zugriffs unter FRITZ!Box-Dienste wird der verwendete Port zufällig ausgewählt
  • Verbesserung - DHCP-Server Gastznetz mit reduzierter LeaseTime von 6 Stunden
  • Verbesserung - FRITZ!Box wiederholt die Registrierung bei MyFRITZ! nicht mehr automatisch
  • Verbesserung - Gültigkeitszeitraum der IP-Adresse (per DHCP vergeben) im Gastnetz separat einstellbar
  • Verbesserung - TR-069 Kommunikation zum Dienstanbieter bei Deaktivierung unter AVM-Dienste komplett unterbunden
  • Verbesserung - diverse Überarbeitungen beim VPN-Import
  • Verbesserung - VPN LAN-LAN Kopplung einer FRITZ!Box am DS-Lite-Anschluss zu IPv4 Gegenstellen ermöglicht
  • Behoben - lokaler FTP-Zugriff via IPv6 scheitert bei Benutzern ohne Internet-Rechte
  • Behoben - Beim herunterladen des FRITZ!Box-Zertifikats unter FRITZ!Box-Dienste zusätzliche Zeichen übermittelt
  • Behoben - FRITZ!Box deregistriert/registriert sich unter Umständen bei Verwendung von Großbuchstaben in der MyFRITZ!-Email-Adresse fortwährend bei myfritz.net
  • Behoben - Gastnetz-Sperre in individuell erstellten Zugangsprofilen der Kindersicherung unwirksam
  • Behoben - Update über FRITZ!OS-Datei scheitert über IPv6
  • Behoben - Sporadische Änderung freigegebener Ports nach Zwangstrennung
  • Behoben - WLAN-Geräte im Gastnetz bekommt keine IP-Adresse über den Repeater
  • Behoben - Lokaler FTP-Zugriff via IPv6 scheitert sofern Benutzer keine Internet-Rechte hat
Telefonie:
  • Behoben - Fehler bei der Anzeige von Kontaktgruppen des Google Telefonbuchs, wenn diese ein "&" enthalten
WLAN:
  • Behoben - Fehlerhafte Repeater-Darstellung auf Seite "WLAN / Funknetz" (7490)
  • Behoben - WLAN-Umgebungsscann terminiert auch bei 160MHz-Kanalbandbreite (HT160) wieder
Heimnetz:
  • Verbesserung - Ändern des Funknetz-Namens ist jetzt optional beim Setzen des FRITZ!Box-Namens
  • Verbesserung - Smart Home Vorlagen können nun in eine weitere über Mesh verbundene FRITZ!Box übernommen werden
  • Behoben - Problem bei der DNS-Auflösung lokaler Heimnetzgeräte im Szenario DHCP ohne Hostname
  • Behoben - mögliches Scheitern der Einrichtung einer Heimnetzverbindung
Sicherheit:
  • Verbesserung - TLS 1.0 Unterstützung für FRITZ!Box in Serverrollen abgeschaltet.
  • Verbesserung - HTTPS-Port im Heimnetz ist nun unabhängig von der Einstellung des WAN-https-Ports
System:
  • Verbesserung - Push-Mail "Neues FRITZ!OS" wird maximal einmal pro Woche versendet
  • Verbesserung - Stabilität
  • Behoben - Kein Import der Einstellungen möglich, wenn Magenta-Cloud aktiviert ist
  • Behoben - Update mit FRITZ!OS-Datei scheitert über IPv6
  • Behoben - Erfolgloser Pushmail-Testversand bei Änderung des Absendernamens
  • Behoben - Info-LED nicht einstellbar (7590)
  • Behoben - Wiederholt erscheinende Meldungen nach erfolgtem Update werden jetzt verhindert
  • Behoben - Problem beim Versand der SMS-Push Service-Mail
  • Änderung - Push Service sendet wichtige Nachrichten von der FRITZ!Box nur noch an den Empfänger der FRITZ!Box-Info-Mail
USB/Speicher/NAS:
  • Verbesserung - Umstellung der SMB-Version auf SMBv3 (v2 unterstützt)
VDSL-Version: 1.180.129.87
DECT: 5.73

https://avm.de/fritz-labor/fritz-la...wlan-repeater-1750e-und-fritzpowerline-1260e/
 
Zuletzt bearbeitet:
  • Like
Reaktionen: bigbay und Meeeenzer
Änderung - Push Service sendet wichtige Nachrichten von der FRITZ!Box nur noch an den Empfänger der FRITZ!Box-Info-Mail
Na endlich, das war einer meiner wichtigsten Wünsche. Was geht es meine Mitnutzer an wenn ich bastele und meine Rufnummer deshalb gestört ist.
 
Bisher alles okay - warten wir es ab, ob es so bleibt! :rolleyes:

Harry
 
Sieht hier bis jetzt alles gut aus - hoffentlich bleibt das so ;-)
Update problemlos durchgelaufen...
 
Die Liste der Änderungen enthält dieses Mal so viele schon länger offene Punkte, daß man diese Labor-Version endlich mal tatsächlich als eine ansehen kann, bei der AVM sich wieder auf die dringenderen Probleme besinnt und erst mal das Vorhandene so umsetzt, daß es auch funktioniert. Sicherlich ist der Spagat zwischen Innovation und "sauberer" Umsetzung der zugesicherten Funktionen nicht immer ganz leicht, aber es hatten sich eben viele kleinere "Nickligkeiten" angesammelt, bei denen man bisher den Eindruck gewinnen konnte, daß diese AVM ziemlich egal wären.

Jetzt fehlt (mir) eigentlich nur noch ein "stabiles" Zertifikat (self-signed) in der FRITZ!Box, damit auch der Zugriff aus dem LAN per HTTPS mal mit einem "pinned certificate" arbeiten kann (zumindest finde ich das in der Liste der Änderungen noch nicht - getestet habe ich nicht, ob es immer noch beim Wechsel der externen IP-Adresse ein neues Zertifikat gibt), nachdem nun offenbar der Port nicht mehr zwangsweise dem externen folgt. Ich kenne jedenfalls keinen (PC-)Browser, der anhand des "public keys" dieses "pinning" vornehmen würde, wie es einige API (Java, Android) möglich machen und wie es auch AVM in den eigenen Apps wohl verwendet.

Einfach weiter so, AVM ... wenn es tatsächlich mal wieder ein neues FRITZ!OS gibt, was auch die letzten neuen Versionen etwas "erdet" (und zu lange unter den Tisch gefallene Probleme behebt), kann das in meinen Augen jedenfalls nicht wirklich schaden und bringt ggf. sogar bei den "Ein-Geräte-Kunden" wieder ein paar Pluspunkte. Dieses Labor-Version werde ich mir jedenfalls wohl auch mal installieren (und sie nicht nur "von außen" ansehen) ... schon weil mich die "diversen Überarbeitungen beim VPN-Import" brennend interessieren (so nebulös diese "Ankündigung" auch zu lesen ist).
 
  • Like
Reaktionen: espresso7
Der angezeigte "aktuelle Energieverbrauch" ist bei beiden Boxen gesunken um ca. 3%.
 
Bug in der GUI:
Wenn man das WLAN deaktiviert, dann bleiben die anderen Einstellungen in der Übersicht sichtbar. Ein Klick auf z.B. Funkkanal, endet in einer Endlosschleife zur Anmeldeseite
upload_2019-1-12_9-16-29.png
 
Hi,

hat jemand die Beta an einem VVDSL-Anschluss aktiv?
Wie sind die Sync- und Fehlerraten?

Bei manchen hatte mit der letzten Beta wohl DLM zugeschlagen.
 
Also an meinem Anschluß ist alles ok. Das einzige was bei mir fast immer auftritt, bei Neustart nach FW Update
ist die verfügbare Bitrate ziemlich weit von der Syncrate. Im Onlinemonitor auf neu Verbinden und dann stimmt
es wieder. Warum das so ist, keine Ahnung. Störabstandsmarge DL um 1dB besser geworden aber das kann auch
Zufall sein und beim nächsten Reboot anders ausfallen.
 
Ich komme mit der neuen Version nicht mehr per via Explorer auf den NAS-Speicher der Box.
.... Zitat gekürzt by stoney
Selbes Problem hier, komme unter Win 10 Pro 1809 nicht mehr per Explorer auf die Box
 
Zuletzt bearbeitet von einem Moderator:
Vollzitat von darüber entfernt by stoney
Hallo,
bei mir ist das gleiche Problem. Ich nutze eine 7590 als Master im Mesh und habe eine 7590 und eine 4040 als Slave. Die 4040 wird in der Netzwerkumgebung angezeigt, von der 7590 Slave sehe ich als Fritz-NAS.
 
Zuletzt bearbeitet von einem Moderator:
hat jemand die Beta an einem VVDSL-Anschluss aktiv?
[...]Bei manchen hatte mit der letzten Beta wohl DLM zugeschlagen.

Du suchst speziell jemand mit einem Telekom VDSL Anschluss? An meinem VDSL Anschluss sieht es gut aus (allerdings WilhemTel ohne DLM). Volle Synchronisation und 0,08 CRC-Fehler auf 4h 37min Uptime. Also alles ganz stark im normalen Rahmen


Zu meinem Problem - AP-/Band-Steering mit 802.11k/v

Von AVM gab es bisher keine speziellen Informationen, wie das technisch funktionieren soll (außer dem Video-Talk der in einem anderen Thread verlinkt wurde). Ich hab das Gefühl, dass das nicht wirklich funktioniert und wollte mal frage, ob das bei Euch sauber klappt. Das gleiche Verhalten hatte ich auch auf der vorherigen Labor. Ich habe folgende Infrastruktur:

1x FRITZ!Box 7590 @7.08-64611 als Mesh-Master (2.4 GHz automatischer Kanal, 5 GHz - Kanal 36 fest (da sonst Netflix-Streaming Algorithmus ständig auf SD runterschraubt))
1x FRITZ!Box 7590 @7.08-64611 als Mesh-Client (mit automatischer Einstellung-Übernahme)
Beide Geräte sind ausschließlich über eine 5 GHz Uplink Verbindung (vom Client zum Master) verbunden

Als Client wird ein Android Smartphone von Sony (XZ2 Compact) genutzt, welches 802.11k/v unterstützt sowie auf Android 9 upgedated ist
Parallel wird die Verbindung über ein Monitor-Mode fähigen Alfa WLAN-Client auf Management-Ebene getraced (Kali Linux)


Annahme:

Ich hab die Funktion bzw. Erweiterung der Mesh-Komfort Funktion so verstanden, dass unter verschiedenen Gesichtspunkten (Signalstärke, Medium-Utilization, Channel-Utilization und was weiß ich was AVM noch alles ranzieht) geprüft wird, ob die Anbindung des WiFi-Clients an das aktuelle WiFi-Radio/VAP noch die beste Wahl ist und wenn dem nicht (mehr) der Fall ist, dass ein BTM-Request (802.11v) ausgelöst wird, der den Client veranlasst sich auf das/ein bessere(s) WiFi-Radio zu verbinden. Das Ganze nicht nur lokal (Band-Steering) sondern auch innerhalb der Mesh-Networks zwischen den Mesh-Teilnehmer (ob nun zu einer FRITZ!Box als Mesh-Client oder FRITZ!Repeater Geräten), sprich AP-Steering.


Mein Problem:

Wenn ich nun meinen WiFi-Client an Mesh-Master anmelde, wird der dort korrekt auf das 5 GHz WiFi gepackt. Ich gehe nun quer durch die Wohnung und verlasse den Signalbereich des Mesh-Masters. Nun wird der WiFi-Client automatisch an den Mesh-Client "angemeldet". Soweit eigentlich so gut, aber das passiert nicht über BTM-Requests an den Client! Am Mesh-Master wird der Client einfach nur deauthentifiziert (4075 2019-01-12 10:20:32,379448 AvmAudio_11:22:33 SonyMobi_11:22:33 802.11 26 Deauthentication, SN=22, FN=0, Flags=........). wland_ctl im Event-Mode zeigt folgendes:

Code:
WLAND_CTL:[INF]Received log event:
   event_id: 754
   max_rate: 866700
   mac: 38:78:62:11:22:33
   band: 0x00000002
   details: 0000011F
WLAND_CTL:[INF]Received state change event:
    mac   = 38:78:62:11:22:33
    role  = 2
    state = 4 -> 1

Folglich führt der WiFi-Client einen erneuten Scan aus und da nun der Mesh-Client das stärkere Signal ausstrahlt (und beide Geräte die gleiches SSID und Schlüssel benutzen) wird er eben dort "normal" angemeldet. Der meshd Ring-Puffer weist zwar versuchte Steering-Events um den Zeitberich der Deauthentication (10:20:32 Uhr) aus, die alle abgebrochen wurden:

Code:
2019-01-12 10:20:23.388 - steering_coordinator: dispatching job for ctx to steer STA 38:78:62:11:22:33 from AP E0:28:6D:11:22:33because of RSSI CROSSING with mode AUTOMATIC
2019-01-12 10:20:23.814 - steering_coordinator: Adding job for ctx to steer STA 38:78:62:11:22:33 from AP E0:28:6D:11:22:33 because of RSSI CROSSING with mode AUTOMATIC to queue!
2019-01-12 10:20:23.878 - steer_state_select_target: [select_target:336] No better link for STA 38:78:62:11:22:33 in 3 options
2019-01-12 10:20:23.880 - steering_coordinator: finished job for ctx to steer STA 38:78:62:11:22:33from AP E0:28:6D:11:22:33 because of RSSI CROSSING with mode AUTOMATIC with result WLAN STEERING ABORT
2019-01-12 10:20:32.887 - NexusNodeService: Getting topology of CC:CE:1E:11:22:33
2019-01-12 10:20:42.388 - steering_coordinator: [dispatch_jobs:483] job for ctx to steer STA 38:78:62:11:22:33 from AP E0:28:6D:11:22:33 because of RSSI CROSSING with mode AUTOMATIC is obsolete. Removing it from queue.

Ich hätte jetzt eigentlich erwartet, dass meshd ein entsprechendes Steering-Event (BTM-Request) auslöst, da ihm die Anbindung an den Mesh-Client über die Mesh-Topologie bekannt ist und, hier weiß ich nicht wie AVM das überhaupt technisch gelöst hat, beide Geräte Werte untereinander tracken.

Folglich ist auf dem Ereignis-Log des Mesh-Master kein entsprechender Eintrag (bis auf WiFi-Client XYZ hat sich abgemeldet) vorhanden, der hier ein AP-Steering verdeutlich. Natürlich könnte ich jetzt über aicmd (aicmd meshd steering steering steer <MAC-Client> 2 3 <MAC-Mesh-Client AP>) ein manuelles AP-Steering ausführen. Dann würde die Ummeldung auch über einen BTM-Request (dafür steht die "2" - Steering-Mode BTM) erfolgen und im Ereignis-Log das korrekte Event erscheinen. Aber ich bin davon ausgegangen das genau dies, dass das automatisiert erfolgt (wenn ein Client 802.11k/v unterstützt), im Rahmen der Erweiterung der Mesh-Komfort Funktion (nun) "von alleine" passiert.


Folge-Problem:

Anschließend zum unter "Mein Problem:" beschrieben Sachverhalt passiert folgendes. Nachdem der WiFi-Client vom Mesh-Master deauthentifiziert wurde und sich dann am Mesh-Client angemeldet hatte, wird er dort ausschließlich auf das 2.4 GHz Radio/VAP gepackt. Warum? Ich würde doch wohl erwarten, dass er dort genauso auf das 5 GHz verbunden werden sollte (auch wenn die "Übergabe" offensichtlich nicht zwischen beiden Boxen "besprochen" wurde), denn Medium-Utilization ist so gut wie Null, es sind 2 weitere APs auf Kanal 36 unterwegs und am Mesh-Client ist bis zu diesem Zeitpunkt kein einziger anderer WiFi-Client angemeldet gewesen.

Gehe ich übrigens aus dem Signalbereich (gleiche Anzahl in Metern und Wänden dazwischen) vom Mesh-Client zurück und lege den WiFi-Client 40 cm vom Mesh-Master enfernt hin, passiert schlicht nichts. Der WiFi-Client hängt nun als Sticky-Client am 2.4 GHz Radio/VAP des Mesh-Client. Selbst wenn ich mich dann noch weiter vom Mesh-Master entferne (in Gegenrichtung zum Mesh-Client) bleibt er da "backen". Erst das aktive Deauthenfizieren (WLAN am Android aus und wieder an) und erneutes Anmelden ermöglicht die Anmeldung am Mesh-Master (auf dessen 5 GHz WiFi-Radio/VAP).


Wie gesagt, da es zu wenige technische Informationen gibt, kann ich iwie nicht feststellen ob das jetzt fehlerhaft ist oder works-as-designed. Und ja ;), ich weiß das AVM die Funktion in eine Labor-Firmware gepackt hat und dass das nicht zwangsläufig laufen muss, aber zumindest eine "Grund-Funktion" wäre schon nett (so zum testen).

Gruß,
Edge
 
Zuletzt bearbeitet:
  • Like
Reaktionen: mono.
Selbes Problem hier, komme unter Win 10 Pro 1809 nicht mehr per Explorer auf die Box
Womöglich liegt es an einem Windows Update vom letzten Patchday. Netzwerkprobleme treten bei Windows 10 nach jedem Patchday vereinzelt auf.
Jedenfalls steckt ein nachvollziehbares System dahinter, wenn der Zugriff bei Windows 10 1809 generell nicht mehr funktioniert. o_O

Ich nutze Windows 10, default-Einstellungen. Ich habe überhaupt nichts deaktiviert. Normal müsste SMBv2 ja standardmäßig funktionieren?
Ja. Übliche Verdächtige sind Tuningtools und Registrycleaner, die übers Ziel hinaus schießen könnnen.
Außerdem Firewalls und AV-Programme, die das Netzwerk filtern.
 
Hab das Problem jetzt temporär per FTP umgangen.
 
SMB funktioniert, man darf allerdings nicht mehr V1 anfordern, das schlägt fehl. Allerdings besteht jetzt nur noch Lesezugriff, auch wenn der User r+w Rechte hat. Muss mal die Platte an den Rechner anschließen...

EDIT: Wenn man Clientseitig die Rechte beim Mount anpasst, so geht das Schreiben wieder...
 
Zuletzt bearbeitet:
Hi,

hat jemand die Beta an einem VVDSL-Anschluss aktiv?
Wie sind die Sync- und Fehlerraten?

Bei manchen hatte mit der letzten Beta wohl DLM zugeschlagen.

Ja, hier mit 100er Leitung der Telekom, seit Beginn an auf 90MBit gedeckelt.

Mit der neuen Beta heftige CRC Fehler und nur einen Speed von 74/36. Vorher 89/41.
Erst nachdem ich auf die vorherige Version geändert habe, ist die Verbindung wieder wie vorher. Der vom Provider gestellte Speed allerdings weiter bei 75/36.

Auch bei mir sind nach einem Neustart die Werte unter aller Sau. erst ein Neu verbinden hilft.
Alles sehr merkwürdig...
 
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.