- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,148
- Punkte für Reaktionen
- 1,705
- Punkte
- 113
Durch den Wunsch in der Liste zum Nachdenken/zur Recherche angeregt, habe ich mich mal etwas eingehender mit "Band steering" befaßt und will mal (mehr als Statement denn als Frage, aber es gibt auch noch eine solche zum Inhalt der Beacon-Pakete bei AVM irgendwo später im Text) meine Sichtweise (und Alternativen zu diesem Verfahren) versuchen zu beschreiben.
Ich hatte das ursprünglich im "Wunschthread" schreiben wollen, aber erst sehr viel später bemerkt, daß das schon wieder sehr sehr lang geworden ist ... und es dort eigentlich ohnehin nicht hingehört. Daher einfach hierher kopiert, einiges muß im Kontext des anderen Threads gelesen werden, damit es einen Zusammenhang gibt.
-
Glücklicherweise ist das dann doch die erwartete (und tatsächlich bekannte) Vorgehensweise ... die APs "verstecken" ihre Netze grundsätzlich (und zwar immer, damit das keine Mißverständnisse erzeugt), damit sind sie für einen passiven Scan "unsichtbar" und so eine Suche nach APs ist eigentlich das, was die meisten Clients und Access-Points machen, wenn sie freie Kanäle und/oder vorhandene Netze finden wollen, auch wenn sie dabei vielleicht mal einen "broadcast probe request" absetzen, der alle APs der Gegend zu einem Advertisement auffordert.
Nur auf einen aktiven Scan hin (das ist der Modus, wo der Client dann entsprechenden Stromverbrauch hat, weil er ständig seinerseits in der aktuellen Umgebung nicht mehr passiv nach irgendwelchen Netzen "lauschen" kann, sondern (mehr oder weniger permanent) nach allen ihm bereits bekannten (oder zumindest in Frage kommenden) Netzen suchen muß/will und das geht eben nur dadurch, daß er seinerseits eine "Anfrage" nach so einer SSID direkt an die damit verknüpfte L2-Adresse (oder im Extremfall auch da wieder als Broadcast, wenn es nur im die SSID geht) verzögern diese APs dann die Antwort im zu meidenden Band etwas, damit sie feststellen können, ob der Client parallel noch im anderen Band sucht. (Alles nach der Beschreibung auf der Cisco-Seite.)
Das mag in Firmen eine halbwegs gangbare Lösung sein, wenn man mal eine entsprechende "Ausdehnung" so eines Netzes unterstellt (auch da braucht es dann schon noch andere Wege, um so einen Client überhaupt zur Suche nach einem Netz zu bewegen, er muß nämlich erst einmal dessen SSID (und ggf. die BSSID, wenn das kein beliebiger AP sein darf, der da antwortet) kennen, damit er überhaupt danach suchen kann), aber an den Stellen, wo sich mehrere Nachbarn so ein WLAN-Band (und ggf. sogar noch WLAN-Kanäle) teilen müssen, ist so ein "hidden node" nur eines, nämlich ein Störsender, der von den anderen immer nur dann zur Kenntnis genommen wird, wenn er selbst sendet oder senden will (also beim CSMA der anderen).
EDIT: Da korrigiere ich mich, der Beschreibung bei Cisco zufolge, wie ein passiver Client den AP dann sieht: "Client devices performing a passive scan will qualify the SSID as hidden.", wird wohl trotzdem ein Beacon-Request regelmäßig gesendet, halt mit leerer SSID (Länge 0).
Dieses Feature ist ja eigentlich in solchen (Profi-)Umgebungen dann auch dafür gedacht, daß das 2,4 GHz-Band in stark ausgelasteten Umgebungen (mit hoher Utilization, aber i.d.R. doch mit nur wenigen ESSIDs) "freigehalten" wird für die "legacy clients", die das 5 GHz-Band technisch nicht nutzen können ... und eher nicht dazu, in doch eher kleinen Heimnetzen (die von mehreren anderen benachbarten Netzen gestört werden) die Clients in das andere Netz zu schieben.
Die nicht ganz unbedeutende Aussage auch auf der Cisco-Webseite ist:
Das möchte ich im Consumer-Bereich so auch eher nicht sehen ... die Probleme sind m.E. vorprogrammiert in der Zusammenarbeit von Stationen mit unterschiedlichen Möglichkeiten. Da ist das "Zwingen" der Clients in ein bestimmtes Band durch unterschiedliche ESSIDs für beide Bänder sicherer und das geht ja - wie erwähnt - bereits heute - es hat auch praktisch kaum Nachteile, solange die Abdeckung stimmt.
Aber damit habe ich das Anliegen dann verstanden.
Das soll ja hier auch eher "Wünsch' Dir was" sein als eine Diskussion der technischen Möglichkeiten und der Sinnhaftigkeit mancher Wünsche - ich hatte nur "das Prinzip" nicht verstanden, weil es eben (nach meiner Kenntnis) keine Ebene im Management von WLAN-AP oder -STA gibt, bei der (halbwegs standardisiert) auf dem einen Band irgendwelche Informationen ausgetauscht werden, was ein Client in einem anderen Band beherrscht und das als Lösung angebotene "Abschalten" als Automatismus so gar keinen Sinn machen wollte in meinen Augen.
-
Bei der Gelegenheit: Hat irgendjemand eine Ahnung (oder eine andere Idee), was AVM mit dem "vendor specific" Teil in einem Beacon-Request übermittelt? Bei mir hat der an einem AP (113.06.51, beide Bänder an, C13 und C112, keine Koexistenz, aber WMM, 50% Sendeleistung) den Wert 0x0101020100000000. Ich hatte irgendwie die Idee, da könnten Daten mit den Crossband-tauglichen Repeatern ausgetauscht werden ... damit man sich nicht ins Gehege kommt. Aber mir fehlt für den Vergleich der notwendige Gerätepark ... vielleicht kann ja mal jemand mit einem Crossband-Repeater in die WLAN-Management-Daten schauen und vergleichen.
Da ich mich ansonsten mit dem WLAN-Mitschnitt auf der FRITZ!Box auch nicht so sehr befasse (eigentlich auch mit dem WLAN der FRITZ!Box an sich kaum, außer es fällt mal wieder aus, weil ich die Firmware falsch ändere), fiel mir erst jetzt auf, daß da bei den Trace-Schnittstellen folgende Beschriftung existiert (wie lange schon - sprich, wie das bei der 06.30 aussah - weiß ich auch nicht):
Anhang anzeigen 86013
Neben der Frage, warum/ob es keine HW-Schnittstelle für "wifi1" gibt, verblüfft mich die Beschriftung für AP2. "ath1" ist bei mir (nach "iwconfig") das Interface im 5 GHz-Band. Nun kommt (nach der Hardware-Liste von @qwertz.asdfgh) ein QCA9558 zum Einsatz, der ist dann wohl "wifi0" - der andere Chipsatz nach der Liste (QCA9880) wäre ja tatsächlich "dualband-tauglich" und insofern stimmt die Beschriftung sogar. Was mich in diesem Zusammenhang jetzt interessiert ... wie verhält sich die 7490 (ich habe leider nur eine und die muß als DSL-Router herhalten) in Betrieb als "WLAN-Repeater"? Kann die tatsächlich (was ja dann zumindest in der Theorie und bei überlappungsfreien Kanälen möglich wäre) auf dem einen 2,4 GHz-Kanal die Verbindung zur FRITZ!Box halten und auf einem anderen zu einer STA? Also so eine Art "Cross-Channel"-Repeating? Ich habe nämlich einen Einsatzfall (ziemlich weitläufiger Garten), wo das Anschauen von Videos mit einem iPad in einiger Entfernung so gar kein wirkliches Vergnügen mehr ist und da könnte so ein Repeater, der das ausschließlich im 2,4 GHz-Band macht (aber auf verschiedenen Kanälen), die Lösung sein. Ich kenne bisher nur Geräte, die das als "Cross-Band"-Repeater machen.
Zurück zum "steering" ...
-
Es wird bei diesem "steering" ja auch nicht der AP wirklich abgeschaltet (was dann die anderen Clients in Mitleidenschaft ziehen würde), er reagiert nur gar nicht auf allgemeine "probe requests" (Type 4 im WLAN-Management, mit einer Broadcast-BSSID) und erfordert damit immer die "gezielte Ansprache" durch einen Client, gleich mit der BSSID (i.d.R. der MAC-Adresse) des AP.
Solange man dann seinem Client (solche Wireless-Geräte arbeiten ja in der überwiegenden Zahl dann auch noch mobil, also ohne permanente Stromversorgung) gezielt die ständige Suche nach weiteren Netzen verbieten kann (schon bei einer ESSID - also einem Netz, was mit einheitlicher SSID von mehreren AP aufgespannt wird, wobei aber jeder davon seine eigene BSSID hat/haben muß - wird das nicht möglich sein, wenn man tatsächlich "roaming" haben will und die STAs damit ständig nach möglicherweise besser zu empfangenden BSS suchen müssen), solange ist das sicherlich eine Möglichkeit. Wenn das aber 10 AP in der Nachbarschaft so machen (also permanent mit "versteckter SSID" unterwegs sind), dann wird auch das schnell lästig, weil es die meisten Algorithmen zur Verteilung der APs (und damit ihrer STAs) über die vorhandenen Kanäle stört und wenn das dann daheim auch noch mit den Smartphones/Tablets der Familie abseits der Ladestation zu einer ständigen Suche nach versteckten Netzen kommt, dann ist das Thema "schlechte Akku-Laufzeit" auch schnell wieder eines, was berücksichtigt werden muß.
Am Ende hat man mit der manuellen Methode beim "Lernen" dieser APs (und dann auch der Repeater) m.E. nur deshalb (und auch nur dann) Erfolg, wenn der Client die Kombination aus SSID (also dem "Namen" des WLANs) und der BSSID (der MAC-Adresse bzw. einer zufälligen "ID", die sich aber dann auch nicht alle 5 Minuten ändern darf) des AP bereits kennt, sie sich dauerhaft merkt und dann eben seinerseits permanent nach dieser Kombination aktiv sucht. Genau das erreicht man dann mit dem Abschalten (egal auf welcher Seite) bei der "ersten Kopplung" ... was vielleicht sogar wieder im Privathaushalt besser klappt als in einem anderen Netz, weil man da eben mal für die Zeit, in der ein neuer Client "herumgeführt" wird, das Netz praktisch abschalten kann.
Ansonsten wäre es m.E. eher auf der Seite des Clients zu regeln ... wenn der Dual-Band beherrscht und Beacons desselben AP (bzw. derselben SSID) in beiden Bändern empfängt, dann ist es für ihn ja viel einfacher, dem Benutzer eine Entscheidung anzubieten, welches Band er bevorzugt benutzen soll. Ich weiß allerdings nicht einmal, ob es tatsächlich (Consumer-)Mobiles gibt, die diese Möglichkeit von sich aus bieten (vielleicht neuere Androiden, bisher war aber m.W. immer eine zusätzliche App erforderlich für so etwas). Bei vielen Windows-Versionen (treiberabhängig) kann man jedenfalls einstellen, welches Band bevorzugt verwendet werden soll und die Einstellung, ob parallel zu einer bestehenden WLAN-Verbindung nach anderen (stärkeren) Netzen gesucht werden soll oder nicht (auch, ob überhaupt aktiv nach "hidden SSIDs" gesucht werden soll), gibt es m.W. spätestens sein Windows 8. Es ist also mehr eine Frage der Einstellungen und Einstellmöglichkeiten am Client als am AP.
Aber auch hier gilt m.E. dann wieder (zumindest bei "Abgabe in haushaltsüblichen Mengen"): Getrennte SSIDs für beide Bänder, dann können auch Repeater und weitere AP nach Herzenslust ihrerseits aktive Beacons aussenden (was auch den Kanal entlastet, denn ein Client, der (durch passives Abhören der Beacons, die an eine Broadcast-Adresse gehen) bereits weiß, daß Netz A mit AP 1 vorhanden wäre, braucht nicht seinerseits aktiv danach zu "pingen" und spätestens wenn man mehr STAs als APs hat, verringert so ein aktives Beacon-Paket die Belegung des Mediums (selbst da kommen aber ca. 10 solcher Beacon-Pakete pro Sekunde), denn ein "probe response"-Paket ist in aller Regel eine zielgerichtete Antwort nur an eine bestimmte MAC-Adresse, nämlich die der anfragenden STA, und wird von anderen STA ignoriert - selbst wenn sie es "entschlüsseln" könnten, weil da noch gar kein Autorisierung/Verschlüsselung greift), die von den Clients entsprechend empfangen und nach "Empfangsqualität" bewertet werden können, um rechtzeitig die Zelle wechseln zu können.
Blöd ist halt nur, wenn man die Reihenfolge der von einem Client zu verwendenden Netze dann nicht festlegen (aka nach Prioritäten sortieren) kann (Kann das iOS es eigentlich inzwischen? Früher war das m.W. mal "alphabetisch", was ja nun so gar keinen Sinn machte.) und damit keine Möglichkeit besteht, bei Vorhandensein der SSID im 5 GHz-Band dieses Netz zu bevorzugen, selbst wenn es (das liegt i.d.R. in der Natur der Sache) eine geringfügig schlechtere Empfangs-/Signalqualität haben sollte, als ein 2,4 GHz-Netz (in gleicher räumlicher Entfernung und nach wenigstens einer Wand, damit die höhere Dämpfung durch andere Medien als Luft auch wirklich Auswirkungen zeigt).
(Mein persönliches) Fazit: Meine Meinung zu solchem "band steering" für eine FRITZ!Box wäre es daher, daß AVM so etwas hoffentlich eher nicht einbaut/in Erwägung zieht. Es macht nicht nur die Konfiguration von WLAN-Parametern in stark belegten Umgebungen schwieriger (und der Ansatzpunkt war es ja, das überlaufene 2,4 GHz- zugunsten des 5 GHz-Bandes zu vermeiden, es kann also auch nicht darum gehen, daß man praktisch alleine "im Äther" ist), sondern ist auch für den normalen Kunden mit (zumindest theoretischen) Nachteilen verbunden, die dieser nicht unbedingt überblickt und am Ende kommt dann nichts weiter dabei heraus als ein "WLAN funktioniert nicht oder nur schlecht", obwohl es sich ggf. nur um eine Fehlkonfiguration (je mehr Einstellungsmöglichkeiten, desto mehr Möglichkeiten für Fehler - das soll aber nur ein Plädoyer für Ausgewogenheit sein und nicht für das "Verstecken" sinnvoller Einstellungen vor dem Kunden) handelt.
Sorry für OT und Überlänge (bei DSL-Leitungen und Beiträgen hier ist länger vermutlich auch nicht immer besser, womit diese Annahme aus einem anderen Bereich auch schon widerlegt wäre) ... wenn ich jetzt Besserung geloben würde, wäre das aber auch nur ein Lippenbekenntnis.
Ich hatte das ursprünglich im "Wunschthread" schreiben wollen, aber erst sehr viel später bemerkt, daß das schon wieder sehr sehr lang geworden ist ... und es dort eigentlich ohnehin nicht hingehört. Daher einfach hierher kopiert, einiges muß im Kontext des anderen Threads gelesen werden, damit es einen Zusammenhang gibt.
-
Glücklicherweise ist das dann doch die erwartete (und tatsächlich bekannte) Vorgehensweise ... die APs "verstecken" ihre Netze grundsätzlich (und zwar immer, damit das keine Mißverständnisse erzeugt), damit sind sie für einen passiven Scan "unsichtbar" und so eine Suche nach APs ist eigentlich das, was die meisten Clients und Access-Points machen, wenn sie freie Kanäle und/oder vorhandene Netze finden wollen, auch wenn sie dabei vielleicht mal einen "broadcast probe request" absetzen, der alle APs der Gegend zu einem Advertisement auffordert.
Nur auf einen aktiven Scan hin (das ist der Modus, wo der Client dann entsprechenden Stromverbrauch hat, weil er ständig seinerseits in der aktuellen Umgebung nicht mehr passiv nach irgendwelchen Netzen "lauschen" kann, sondern (mehr oder weniger permanent) nach allen ihm bereits bekannten (oder zumindest in Frage kommenden) Netzen suchen muß/will und das geht eben nur dadurch, daß er seinerseits eine "Anfrage" nach so einer SSID direkt an die damit verknüpfte L2-Adresse (oder im Extremfall auch da wieder als Broadcast, wenn es nur im die SSID geht) verzögern diese APs dann die Antwort im zu meidenden Band etwas, damit sie feststellen können, ob der Client parallel noch im anderen Band sucht. (Alles nach der Beschreibung auf der Cisco-Seite.)
Das mag in Firmen eine halbwegs gangbare Lösung sein, wenn man mal eine entsprechende "Ausdehnung" so eines Netzes unterstellt (auch da braucht es dann schon noch andere Wege, um so einen Client überhaupt zur Suche nach einem Netz zu bewegen, er muß nämlich erst einmal dessen SSID (und ggf. die BSSID, wenn das kein beliebiger AP sein darf, der da antwortet) kennen, damit er überhaupt danach suchen kann), aber an den Stellen, wo sich mehrere Nachbarn so ein WLAN-Band (und ggf. sogar noch WLAN-Kanäle) teilen müssen, ist so ein "hidden node" nur eines, nämlich ein Störsender, der von den anderen immer nur dann zur Kenntnis genommen wird, wenn er selbst sendet oder senden will (also beim CSMA der anderen).
EDIT: Da korrigiere ich mich, der Beschreibung bei Cisco zufolge, wie ein passiver Client den AP dann sieht: "Client devices performing a passive scan will qualify the SSID as hidden.", wird wohl trotzdem ein Beacon-Request regelmäßig gesendet, halt mit leerer SSID (Länge 0).
Dieses Feature ist ja eigentlich in solchen (Profi-)Umgebungen dann auch dafür gedacht, daß das 2,4 GHz-Band in stark ausgelasteten Umgebungen (mit hoher Utilization, aber i.d.R. doch mit nur wenigen ESSIDs) "freigehalten" wird für die "legacy clients", die das 5 GHz-Band technisch nicht nutzen können ... und eher nicht dazu, in doch eher kleinen Heimnetzen (die von mehreren anderen benachbarten Netzen gestört werden) die Clients in das andere Netz zu schieben.
Die nicht ganz unbedeutende Aussage auch auf der Cisco-Webseite ist:
Das fällt also generell aus, wenn man z.B. irgendwelche Geräte hat, die ihrerseits gar nicht dazu gebracht werden können, so ein "wireless network" ohne passende sichtbare(!) SSID (d.h. ohne aktive Beacons) zu nutzen. Eine Mindestvoraussetzung (zumindest wenn man das mit Roaming zwischen APs machen will) wäre schon mal die Verwaltung der bisher bekannten WLANs, zu denen das Gerät schon einmal Kontakt hatte. Das scheitert (zumindest bei dem, was ich in so einem Privathaushalt an Geräten so kenne) spätestens am Drucker, da kenne ich kein Consumer-Modell, welches mehr als eine WLAN-Verbindung speichert - das liegt sicherlich auch daran, daß solche Geräte eher nicht für's Roaming geeignet sind. Wenn man Glück hat, lassen die sich aber zumindest noch für eine "hidden SSID" konfigurieren, weil man diese direkt eingeben kann.
Das möchte ich im Consumer-Bereich so auch eher nicht sehen ... die Probleme sind m.E. vorprogrammiert in der Zusammenarbeit von Stationen mit unterschiedlichen Möglichkeiten. Da ist das "Zwingen" der Clients in ein bestimmtes Band durch unterschiedliche ESSIDs für beide Bänder sicherer und das geht ja - wie erwähnt - bereits heute - es hat auch praktisch kaum Nachteile, solange die Abdeckung stimmt.
Aber damit habe ich das Anliegen dann verstanden.
Das soll ja hier auch eher "Wünsch' Dir was" sein als eine Diskussion der technischen Möglichkeiten und der Sinnhaftigkeit mancher Wünsche - ich hatte nur "das Prinzip" nicht verstanden, weil es eben (nach meiner Kenntnis) keine Ebene im Management von WLAN-AP oder -STA gibt, bei der (halbwegs standardisiert) auf dem einen Band irgendwelche Informationen ausgetauscht werden, was ein Client in einem anderen Band beherrscht und das als Lösung angebotene "Abschalten" als Automatismus so gar keinen Sinn machen wollte in meinen Augen.
-
Bei der Gelegenheit: Hat irgendjemand eine Ahnung (oder eine andere Idee), was AVM mit dem "vendor specific" Teil in einem Beacon-Request übermittelt? Bei mir hat der an einem AP (113.06.51, beide Bänder an, C13 und C112, keine Koexistenz, aber WMM, 50% Sendeleistung) den Wert 0x0101020100000000. Ich hatte irgendwie die Idee, da könnten Daten mit den Crossband-tauglichen Repeatern ausgetauscht werden ... damit man sich nicht ins Gehege kommt. Aber mir fehlt für den Vergleich der notwendige Gerätepark ... vielleicht kann ja mal jemand mit einem Crossband-Repeater in die WLAN-Management-Daten schauen und vergleichen.
Da ich mich ansonsten mit dem WLAN-Mitschnitt auf der FRITZ!Box auch nicht so sehr befasse (eigentlich auch mit dem WLAN der FRITZ!Box an sich kaum, außer es fällt mal wieder aus, weil ich die Firmware falsch ändere), fiel mir erst jetzt auf, daß da bei den Trace-Schnittstellen folgende Beschriftung existiert (wie lange schon - sprich, wie das bei der 06.30 aussah - weiß ich auch nicht):
Anhang anzeigen 86013
Neben der Frage, warum/ob es keine HW-Schnittstelle für "wifi1" gibt, verblüfft mich die Beschriftung für AP2. "ath1" ist bei mir (nach "iwconfig") das Interface im 5 GHz-Band. Nun kommt (nach der Hardware-Liste von @qwertz.asdfgh) ein QCA9558 zum Einsatz, der ist dann wohl "wifi0" - der andere Chipsatz nach der Liste (QCA9880) wäre ja tatsächlich "dualband-tauglich" und insofern stimmt die Beschriftung sogar. Was mich in diesem Zusammenhang jetzt interessiert ... wie verhält sich die 7490 (ich habe leider nur eine und die muß als DSL-Router herhalten) in Betrieb als "WLAN-Repeater"? Kann die tatsächlich (was ja dann zumindest in der Theorie und bei überlappungsfreien Kanälen möglich wäre) auf dem einen 2,4 GHz-Kanal die Verbindung zur FRITZ!Box halten und auf einem anderen zu einer STA? Also so eine Art "Cross-Channel"-Repeating? Ich habe nämlich einen Einsatzfall (ziemlich weitläufiger Garten), wo das Anschauen von Videos mit einem iPad in einiger Entfernung so gar kein wirkliches Vergnügen mehr ist und da könnte so ein Repeater, der das ausschließlich im 2,4 GHz-Band macht (aber auf verschiedenen Kanälen), die Lösung sein. Ich kenne bisher nur Geräte, die das als "Cross-Band"-Repeater machen.
Zurück zum "steering" ...
-
Es wird bei diesem "steering" ja auch nicht der AP wirklich abgeschaltet (was dann die anderen Clients in Mitleidenschaft ziehen würde), er reagiert nur gar nicht auf allgemeine "probe requests" (Type 4 im WLAN-Management, mit einer Broadcast-BSSID) und erfordert damit immer die "gezielte Ansprache" durch einen Client, gleich mit der BSSID (i.d.R. der MAC-Adresse) des AP.
Solange man dann seinem Client (solche Wireless-Geräte arbeiten ja in der überwiegenden Zahl dann auch noch mobil, also ohne permanente Stromversorgung) gezielt die ständige Suche nach weiteren Netzen verbieten kann (schon bei einer ESSID - also einem Netz, was mit einheitlicher SSID von mehreren AP aufgespannt wird, wobei aber jeder davon seine eigene BSSID hat/haben muß - wird das nicht möglich sein, wenn man tatsächlich "roaming" haben will und die STAs damit ständig nach möglicherweise besser zu empfangenden BSS suchen müssen), solange ist das sicherlich eine Möglichkeit. Wenn das aber 10 AP in der Nachbarschaft so machen (also permanent mit "versteckter SSID" unterwegs sind), dann wird auch das schnell lästig, weil es die meisten Algorithmen zur Verteilung der APs (und damit ihrer STAs) über die vorhandenen Kanäle stört und wenn das dann daheim auch noch mit den Smartphones/Tablets der Familie abseits der Ladestation zu einer ständigen Suche nach versteckten Netzen kommt, dann ist das Thema "schlechte Akku-Laufzeit" auch schnell wieder eines, was berücksichtigt werden muß.
Am Ende hat man mit der manuellen Methode beim "Lernen" dieser APs (und dann auch der Repeater) m.E. nur deshalb (und auch nur dann) Erfolg, wenn der Client die Kombination aus SSID (also dem "Namen" des WLANs) und der BSSID (der MAC-Adresse bzw. einer zufälligen "ID", die sich aber dann auch nicht alle 5 Minuten ändern darf) des AP bereits kennt, sie sich dauerhaft merkt und dann eben seinerseits permanent nach dieser Kombination aktiv sucht. Genau das erreicht man dann mit dem Abschalten (egal auf welcher Seite) bei der "ersten Kopplung" ... was vielleicht sogar wieder im Privathaushalt besser klappt als in einem anderen Netz, weil man da eben mal für die Zeit, in der ein neuer Client "herumgeführt" wird, das Netz praktisch abschalten kann.
Ansonsten wäre es m.E. eher auf der Seite des Clients zu regeln ... wenn der Dual-Band beherrscht und Beacons desselben AP (bzw. derselben SSID) in beiden Bändern empfängt, dann ist es für ihn ja viel einfacher, dem Benutzer eine Entscheidung anzubieten, welches Band er bevorzugt benutzen soll. Ich weiß allerdings nicht einmal, ob es tatsächlich (Consumer-)Mobiles gibt, die diese Möglichkeit von sich aus bieten (vielleicht neuere Androiden, bisher war aber m.W. immer eine zusätzliche App erforderlich für so etwas). Bei vielen Windows-Versionen (treiberabhängig) kann man jedenfalls einstellen, welches Band bevorzugt verwendet werden soll und die Einstellung, ob parallel zu einer bestehenden WLAN-Verbindung nach anderen (stärkeren) Netzen gesucht werden soll oder nicht (auch, ob überhaupt aktiv nach "hidden SSIDs" gesucht werden soll), gibt es m.W. spätestens sein Windows 8. Es ist also mehr eine Frage der Einstellungen und Einstellmöglichkeiten am Client als am AP.
Aber auch hier gilt m.E. dann wieder (zumindest bei "Abgabe in haushaltsüblichen Mengen"): Getrennte SSIDs für beide Bänder, dann können auch Repeater und weitere AP nach Herzenslust ihrerseits aktive Beacons aussenden (was auch den Kanal entlastet, denn ein Client, der (durch passives Abhören der Beacons, die an eine Broadcast-Adresse gehen) bereits weiß, daß Netz A mit AP 1 vorhanden wäre, braucht nicht seinerseits aktiv danach zu "pingen" und spätestens wenn man mehr STAs als APs hat, verringert so ein aktives Beacon-Paket die Belegung des Mediums (selbst da kommen aber ca. 10 solcher Beacon-Pakete pro Sekunde), denn ein "probe response"-Paket ist in aller Regel eine zielgerichtete Antwort nur an eine bestimmte MAC-Adresse, nämlich die der anfragenden STA, und wird von anderen STA ignoriert - selbst wenn sie es "entschlüsseln" könnten, weil da noch gar kein Autorisierung/Verschlüsselung greift), die von den Clients entsprechend empfangen und nach "Empfangsqualität" bewertet werden können, um rechtzeitig die Zelle wechseln zu können.
Blöd ist halt nur, wenn man die Reihenfolge der von einem Client zu verwendenden Netze dann nicht festlegen (aka nach Prioritäten sortieren) kann (Kann das iOS es eigentlich inzwischen? Früher war das m.W. mal "alphabetisch", was ja nun so gar keinen Sinn machte.) und damit keine Möglichkeit besteht, bei Vorhandensein der SSID im 5 GHz-Band dieses Netz zu bevorzugen, selbst wenn es (das liegt i.d.R. in der Natur der Sache) eine geringfügig schlechtere Empfangs-/Signalqualität haben sollte, als ein 2,4 GHz-Netz (in gleicher räumlicher Entfernung und nach wenigstens einer Wand, damit die höhere Dämpfung durch andere Medien als Luft auch wirklich Auswirkungen zeigt).
(Mein persönliches) Fazit: Meine Meinung zu solchem "band steering" für eine FRITZ!Box wäre es daher, daß AVM so etwas hoffentlich eher nicht einbaut/in Erwägung zieht. Es macht nicht nur die Konfiguration von WLAN-Parametern in stark belegten Umgebungen schwieriger (und der Ansatzpunkt war es ja, das überlaufene 2,4 GHz- zugunsten des 5 GHz-Bandes zu vermeiden, es kann also auch nicht darum gehen, daß man praktisch alleine "im Äther" ist), sondern ist auch für den normalen Kunden mit (zumindest theoretischen) Nachteilen verbunden, die dieser nicht unbedingt überblickt und am Ende kommt dann nichts weiter dabei heraus als ein "WLAN funktioniert nicht oder nur schlecht", obwohl es sich ggf. nur um eine Fehlkonfiguration (je mehr Einstellungsmöglichkeiten, desto mehr Möglichkeiten für Fehler - das soll aber nur ein Plädoyer für Ausgewogenheit sein und nicht für das "Verstecken" sinnvoller Einstellungen vor dem Kunden) handelt.
Sorry für OT und Überlänge (bei DSL-Leitungen und Beiträgen hier ist länger vermutlich auch nicht immer besser, womit diese Annahme aus einem anderen Bereich auch schon widerlegt wäre) ... wenn ich jetzt Besserung geloben würde, wäre das aber auch nur ein Lippenbekenntnis.
Zuletzt bearbeitet:
