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
