FRITZ!Repeater 2400 / FRITZ!OS 7.50 vom 05.01.2023

[Grisu_]

Kenne es nur von meiner WLAN-Repeater-Box 7590.
Und da kann ich bei Mesh zwar einstellen mit welcher MAC er sich verbinden soll (pro 2,4 und 5GHz), jedoch kann ich nicht mehrere auswählen, falls ich die Entscheidung offen lassen möchte.
Und obendrein pfeifft er dann sowieso auf den ausgewählten Zugangspunkt und nimmt irgendeinen mit der SSID/PW wenn der eingestellte grad nicht verfügbar ist.

 

[stoney]

Ja die FRITZ!Produkte binden sich an die MAC, sonst würde ja die Reihenschaltung nicht zuverlässig funktionieren, aber solche Geräte sind eben keine "normalen" Clients.

Wenn der eigentliche Zugangspunkt "ausfällt" suchen diese sich eine Alternative, aber ein automatischen zurückwechseln funktioniert wohl aktuell noch nicht, wenn er eigentlich eingerichtete AP wieder zur Verfügung steht, da hilft wohl nur ein Neustart (alternativ auf dem MeshRepeater das WLAN aus-/anschalten - geht aber dann eben nur, falls der Client, welcher die GUI öffnet des MeshRepeaters per LAN verbudnen ist, sonst schießt man sich ja selbst ab).

Alternativ könnte man natürlich über die WLAN Zeitschaltung - in 15 Minuten-Schritten es "umgehen" oder bei einer F!Box über den WLAN-Taster es schneller manuell machen - wobei man die Zeitschaltung dann wieder händisch deaktivieren müsste.

 

[Thomas5]

Das ist das normale in der Norm definierte Verhalten eines Clients: Die Verbindung mit einem AP wird so lange gehalten, bis sie abreißt. Erst DANACH wird eine neue Verbindung gesucht. Diese wird dann erneut gehalten, bis sie wieder unterbrochen wird. Erst mit der Einführung von Mesh wurde mit IEEE 802.11k und 802.11v die Möglichkeit geschaffen, bei laufender Verbindung den AP zu wechseln.
Wenn ich Mesh - aus welchem Grund auch immer - deaktiviere, verzichte ich auch auf diese Möglichkeit. Man kann halt nicht alles haben…

 

[Exodus88]

Hallo @Thomas5

in der Theorie ist das absolut richtig, was du schreibst, nur in der Praxis sieht das leider etwas anders aus.

Der Vorteil von Mesh-Steering ist, dass bei einem Band oder AP Wechsel die Verbindung nicht unterbrochen wird. Das ist z. Bsp. Wichtig für WLAN-Call, oder Videotelefonie usw.
In der Regel bedient sich aber der Client mit WLAN-Roaming. Dabei sucht sich der Client das Band oder den AP selbstständig aus und dabei wird die Verbindung zum Heimnetz bei einem Wechsel kurz unterbrochen.

AVM preist sein Mesh System als "EierlegendeWollMilchSau" an, und schreibt, dass die Clients gesteuert werden usw... In 98% der Fälle entscheidet aber der Client selbst, mit welchen AP oder Band er sich verbindet. Die Gründe dafür sind auch relativ einfach zu finden. Der Client ist mit seiner Entscheidung einfach schneller als die "Empfehlung" die vom Mesh Master kommt. Und dann handelt es sich immer noch um eine Empfehlung, die der Client in keinster Weise nachkommen muss/will.

Hier ein kurzes Beispiel von gerade eben. Ich bewegte mich mit meinem Samsung S21 ultra zwischen der Masterbox 6690 und zwei Clinetboxen 7580 und 7590 ax.



Man findet keinen einzigen Eintrag, dass AVM den Client gesteuert hätte.
Im Übrigen finde ich in meiner 6690 keinen einzigen Eintrag von Band oder AP Steering.

Wenn ein Wechsel erfolgt, der von AVM angestoßen wurde, sehen die Einträge im erweiterten WLAN-Log so aus...

WLAN-Gerät wurde umgemeldet (Band-Steering): Automatischer WLAN-Bandwechsel zur verbesserten Datenübertragung, xxxx, xxx MAC xxx

oder

WLAN-Gerät wurde umgemeldet (AP-Steering): Automatischer Wechsel des WLAN-Gerätes xxx, IP xxxx, MAC xxx zur verbesserten Datenübertragung (von 3000axRepeater-AP zu 1200axRepeaterTeich, Grund: Verbindung zu schlecht).

Du kannst bei dir gerne mal nachsehen, ob und wie viel solcher Einträge du findest, und wie die im Verhältnis zum normalen "Wlan-Roamning" stehen.

Gruß

Roland

 

[Thomas5]

Das ist dann aber ein Problem der Clients und nicht der AVM-Geräte.
Ich habe übrigens ausschließlich(!) von der Fritz angestoßene Steering-Meldungen in meinem WLAN-Log (sechs in den letzten 24 Stunden, die meisten unserer WLAN-Clients sind ortsfest).
Edit: Ich muss meine Aussage berichtigen. Der Haken für erweiterte WLAN-Protokollierung war nicht gesetzt, was mir erst nach einem Neustart aufgefallen ist. Ich habe außer den Band-Steering- und AP-Steering-Meldungen auch die von Roland beschriebenen An- und Abmeldungen. Sorry!

 

[NDiIPP]

Das folgende

Die Verbindung mit einem AP wird so lange gehalten, bis sie abreißt. Erst DANACH wird eine neue Verbindung gesucht.

ist mittlerweile nicht mehr bei allen WiFi-Clients das übliche Verhalten. Viele wechseln mittlerweile schon zuvor den AP und kommen nicht selten einem WiFi-Controller gesteuertem AP-/Band-Steering zuvor.

 

[Thomas5]

Deswegen schrieb ich auch "das normale in der Norm definierte Verhalten"...

 

[NDiIPP]

"das normale in der Norm definierte Verhalten"

Interessant, in welcher Norm ist das von dir beschriebene Verhalten festgelegt bzw. als "normal" definiert?

 

[Exodus88]

Hallo @Thomas5

danke für deine Antwort.

Ich würde das nicht als Clientproblem bezeichnen, wenn hier der AP oder Band selbstständig gewechselt wird.
Warum sollte hier der Client warten, bis sich die Masterbox entscheidet, eine Empfehlung auszusprechen.
Wenn das mit dem Client schneller geht und dabei die RSSI bzw. Stabilität verbessert wird, ist das doch absolut ok.

Wärst du mal so nett und würdest einen Screenshot deines WLAN Logs hochladen, wäre wirklich interessant zu sehen, wie das bei dir aussieht.

Ansonsten macht z. Bsp. Das von mir genutzte Smartphone im zweiten Netz auf der Hofstelle, das AVM Steering problemlos mit, genauso wie die anderen Smartphones meiner Familie. Evtl. hat es etwas mit der 6690 zu tun.

Gruß

Roland

 

[Thomas5]

@NDiIPP IEEE 802.11-2016

@Exodus88 Mussten die Fritte heute Mittag neu starten, daher ist das Log jetzt leider erstmal leer. Werde ich aber nachliefern, sobald es sich wieder gefüllt hat. *Edit* Bitte meine editierte Anmerkung in #85 beachten.

 

[NDiIPP]

IEEE 802.11-2016

Und du bist dir sicher, dass das von dir beschriebene Verhalten bzgl. vom Client kontrolliertem Roaming-Verhalten (ohne Zuhilfenahme von bspw. 802.11f oder 802.11r) darin als normal beschrieben ist? Denn in der Realität ist das (mittlerweile) bei vielen Clients nicht das normale Verhalten (und daher würde mich das wundern).

 

[Thomas5]

802.11f gibt es nicht mehr, der Standard wurde bereits vor 17 Jahren zurückgezogen! Und 802.11r ist die als "Mesh" bekannte Erweiterung um Seamless Roaming. Aber Mesh sollte doch gerade nicht benutzt werden, oder habe ich da jetzt was völlig missverstanden?

 

[NDiIPP]

Eben, deshalb schrieb ich ja "ohne Zuhilfenahme von bspw. 802.11f oder 802.11r" (daher spielt es auch keine Rolle, das 802.11f zurückgezogen wurde). Meine Frage bleibt also bestehen, denn ich bin nach wie vor skeptisch!

 

[Thomas5]

Irgendwie reden wir hier aneinander vorbei. In Beitrag #80 machte @stoney den Vorschlag, allen Accesspoints eigene SSID zuzuordnen. Darauf bezog sich meine Aussage in Beitrag #83. Wenn ich drei Accesspoints habe (AP1 mit SSID1, AP2 mit SSID2 und AP3 mit SSID3) und mein Client ist mit SSID1 am AP1 verbunden, dann wird er dort so lange bleiben, bis die Verbindung abreißt. Danach sucht er wieder nach Funknetzen und wird sich gegebenenfalls mit den ihm bekannten SSID 2 oder 3 verbinden. Solange aber eine Verbindung zur SSID1 besteht, wird ein Client (egal ob modern oder nicht) NIEMALS eigenständig zu einer anderen SSID wechseln, nur weil deren AP gerade stärker zu empfangen ist. Für den Client sind das drei verschiedene Funknetze, zwischen denen gibt es kein Roaming! Das ginge nur, wenn die SSID identisch wären.
Ich hoffe, jetzt ist klar was ich meinte. Und gleich gibt es wieder einen Rüffel, weil wir Off Topic werden…

 

[NDiIPP]

Irgendwie reden wir hier aneinander vorbei.

Scheint so zu sein. Denn darauf, dass du das nur auf den Vorschlag aus #80 bezogen hattest (mit abweichenden SSIDs), hatte ich nicht erkannt.

Edit:
Andererseits war dann die folgende Aussage in diesem Zusammenhang imo ein wenig Irreführend:

Erst mit der Einführung von Mesh wurde mit IEEE 802.11k und 802.11v die Möglichkeit geschaffen, bei laufender Verbindung den AP zu wechseln.

Denn das war eben auch zuvor ohne Mesh bzw. 802.11k/v möglich (vom Client kontrolliertes Roaming), wenn auch ggf. mit einer entspr. kurzen Unterbrechung, die aber dennoch nicht in jeden Fall (negativ) auffallen muss.

 

[Thomas5]

Tut mir leid, wenn ich mich da unklar ausgedrückt habe.

 

[deomaki]

Habe zwei Räume, die keine TV Dose haben und somit per Live-TV über WLAN versorgt werden müssen.
Habe meine 2400er auf 7.50 upgedatet. War ne dumme Idee: Live-TV quasi unbrauchbar. Nur noch Ruckler, Bild- und Tonaussetzer, Asynchronizität bei Ton/Bild, Artefakte und Standbilder an sämtlichen Typen von Endgeräten (also Geräte unabhängig): TV-Boxen, Laptops, FritzTV App am Handy...
Eine Downgrade Möglichkeit per Aufspielen eines alten OS gibt es nicht :-(
AVM Support ist kontaktiert. Mal sehen, was passiert!
Kennt/hat von euch jemand das Problem auch?

 

[Exodus88]

Downgraden kannst du nur über das Recovery.

 

[stoney]

Oder linux_fs_start falls die gewünschte Version zuletzt/zuvor installiert war

 

[juergen5]

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

Hallo deomaki,
war es Dir möglich ein Downgrade hinzubekommen ?
Für mich ist die 2400er mit der 7.50 ebenfalls leider unbrauchbar geworden. Schade !
Danke fürs antworten!
Jürgen