WIFI: Probleme beim Roaming mit unterschiedlichen Clients
Hallo zusammen, hoffe ihr seid gut in die Woche gestartet
Folgende Ausgangslage
Hardware:
Software: Androidanwendung mit integriertem Browser, welche auf SAP System zugreift. (Zugriff per Chrome am Tablet zeigt selbes Problem, am PC per LAN keine Probleme)
Problem
Hauptsächlich beim Roaming, aber auch während der Verbindung mit demselben AP bricht die Verbindung zu Gateway und sämtlichen Zielsystemen weg, währen die WLAN Verbindung bestehen bleibt. Das Problem ist nicht auf ein Endgerät zurückzuführen sondern betrifft alle. Auch Windows Notebooks.
Konfiguration
SSID (WPA2-PSK)
RF-ARM
RF-Funk
Weitere Informationen
Ich komme aktuell nicht weiter und würde mich wahnsinnig über jeden Tip von euch freuen. Meine letzte Vermutung war noch MAC-Aging auf den Switches, habe ich aber noch nicht überprüft.
Bedanke mich schonmal im Voraus, wenn ihr noch weitere Infos braucht: Gern her damit!
Liebe Grüße
mininik
Folgende Ausgangslage
Hardware:
- Zebra ET51 Android Tablets (aktuellste Firmware)
- Zebra MC330L Android Handscanner (aktuellste Firmware)
- Zebra ZQ521 Drucker (aktuellste Firmware, sämtliche Stromsparfunktionen und Standbyfunktionen deaktiviert)
- Aruba IAP-515 Cluster (aktuellste Firmware)
- Diverse Aruba und Procurve Accessswitche (aktuellste Firmware)
- Core Switch: Procurve 5308XL (aktuellste Firmware; ich weiß uralter Schinken, wird in 3 Wochen ausgetauscht)
Software: Androidanwendung mit integriertem Browser, welche auf SAP System zugreift. (Zugriff per Chrome am Tablet zeigt selbes Problem, am PC per LAN keine Probleme)
Problem
Hauptsächlich beim Roaming, aber auch während der Verbindung mit demselben AP bricht die Verbindung zu Gateway und sämtlichen Zielsystemen weg, währen die WLAN Verbindung bestehen bleibt. Das Problem ist nicht auf ein Endgerät zurückzuführen sondern betrifft alle. Auch Windows Notebooks.
Konfiguration
SSID (WPA2-PSK)
RF-ARM
RF-Funk
Weitere Informationen
- Ausleuchtung wurde durch externe Firma übernommen
- 5GHz bringt keine Besserung
- Kanäle wurden angepasst, dass auf benachbarten APs nicht derselbe Kanal verwendet wird
- Signalstärke wurde auf APs angepasst
- Laut ext. Firma sind Kanäle 1,6,11 zwar reichlich belegt, sollte aber keinen Einfluss auf Funktion haben
- Accesspoints laufen in separatem Subnetz als Cluster
- Clients laufen in separatem Subnetz
- Firewall hängt nicht dazwischen, IDS auf dem Aruba Cluster ist deaktiviert
- Habe mich mit Laptop auf jeden Uplinkport der Accesspoints am Switch verbunden, keine Verbindungsprobleme
- Core Switch hat keine ACLs
- Roaming mit Netally Aircheck G2 getestet, läuft sauber
Ich komme aktuell nicht weiter und würde mich wahnsinnig über jeden Tip von euch freuen. Meine letzte Vermutung war noch MAC-Aging auf den Switches, habe ich aber noch nicht überprüft.
Bedanke mich schonmal im Voraus, wenn ihr noch weitere Infos braucht: Gern her damit!
Liebe Grüße
mininik
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7897563338
Url: https://administrator.de/forum/wifi-probleme-beim-roaming-mit-unterschiedlichen-clients-7897563338.html
Ausgedruckt am: 24.12.2024 um 16:12 Uhr
5 Kommentare
Neuester Kommentar
Ein Fehler oben ist 802.11d/h nicht zu aktivieren, das sollte man immer machen in WLANs.
Das Allerwichtigste zur eigentlichen Thread Thematik hast du aber gar nicht erwähnt. WIE ist das Roaming überhaupt eingestellt an den APs?
Zumindestens 802.11r sollte in jedem Falle aktiviert sein, damit du ein proaktives AP basiertes Fast Roaming machst.
Idealerweise in Verbindung mit 802.11k
Damit erreichst du ein deutlich agileres Roaming.
Hast du keinerlei Roaming auf den APs aktiviert (oben ist nichts dergleichen zu sehen ) dann bleibst du bei dem passiven Client Roaming hängen mit all seinen negativen Eigenschaften wo die Clients solange an einem AP kleben unter runtertakten der Sessionrate bis gar nichts mehr geht. Client Roaming ist, wenn man so will, in Wahrheit gar kein Roaming.
Damit kommt es immer zu einem vollständigen Abbruch der AP Verbindung und einer Neuassoziierung des Clients mit einem anderen AP und erneuter Neuaushandlung der Verschlüsselung was immer eine vollständige, längere Unterbrechung der Verbindung nach sich zieht.
Mit aktivem .11r / .11k passiert das nicht, weil die APs untereinander den Client unterbrechungsfrei von einer Funkzelle in die andere immer mit der besten Feldstärke (RSSID Wert) hieven. Analog zum Telefon Mobilnetz wo es nicht einmal zur Sprachunterbrechung kommt wenn man die Zelle wechselt.
Das Allerwichtigste zur eigentlichen Thread Thematik hast du aber gar nicht erwähnt. WIE ist das Roaming überhaupt eingestellt an den APs?
Zumindestens 802.11r sollte in jedem Falle aktiviert sein, damit du ein proaktives AP basiertes Fast Roaming machst.
Idealerweise in Verbindung mit 802.11k
Damit erreichst du ein deutlich agileres Roaming.
Hast du keinerlei Roaming auf den APs aktiviert (oben ist nichts dergleichen zu sehen ) dann bleibst du bei dem passiven Client Roaming hängen mit all seinen negativen Eigenschaften wo die Clients solange an einem AP kleben unter runtertakten der Sessionrate bis gar nichts mehr geht. Client Roaming ist, wenn man so will, in Wahrheit gar kein Roaming.
Damit kommt es immer zu einem vollständigen Abbruch der AP Verbindung und einer Neuassoziierung des Clients mit einem anderen AP und erneuter Neuaushandlung der Verschlüsselung was immer eine vollständige, längere Unterbrechung der Verbindung nach sich zieht.
Mit aktivem .11r / .11k passiert das nicht, weil die APs untereinander den Client unterbrechungsfrei von einer Funkzelle in die andere immer mit der besten Feldstärke (RSSID Wert) hieven. Analog zum Telefon Mobilnetz wo es nicht einmal zur Sprachunterbrechung kommt wenn man die Zelle wechselt.
bisher war passives Client Roaming aktiv.
Aber oben sagtest du doch das du .11r aktiv hast? 🤔 Geht ja nur entweder oder....11r besonders im Zusammenspiel mit .11k löst in der Regel das Roaming Thema umfassend.
Möglich aber auch das du ggf. noch Hidden Station Problematiken im Netz hast. Da gibts dann auch wieder was aber warten wir erstmal ab.