Inzwischen ist das Netz „voll“ davon: Link. Wer auch immer sich auf das neue Yosemite gefreut hat, kommt mehr oder weniger in’s Schwitzen. Hat er aktualisiert und besitzt einen Mac mit Broadcomm WiFi Chipsatz, so wird’s – spätestens nach der Freischaltung der Funktionen für iOS (SMS/FaceTime/usw.) schnell zappenduster. Ein wenig Abhilfe kann ich hier leisten mit ein paar Tipps, ein paar Ansätze für Firmenadministratoren.
Update 31.10.2014, mit Korrekturen von Alfred – lancom-forum.de
Update 12.11.2014, mit Lösungsregelwerk
Vermeintlich verbunden und doch so weit entfernt – Ein Yosemite Macbook und der nächste Accesspoint
tl;dr: Es gibt ein Update (12.11.2014) Entscheidenden Einfluss auf dieses Regelwerk zur Lösung hat (mal wieder) das Unternehmen Lancom. Vielen Dank!
Generell gilt, Yosemite überprüft ab sofort die Länderkennung des entsprechenden Accesspoints, um dem Anwender verschiedene Features zur Verfügung zu stellen oder zu verweigern. Eine fehlerhafte Kennung (welche hierzulande DE entspricht) sorgt dafür, dass Datenraten von maximal 54M möglich sind. Für die Konfiguration bzw. Lösung des Problems sind „vernünftige“ Accesspoints oder WLAN-Controller-Lösungen erforderlich. Manche China-Ware hat hier einfach die verkehrte Länderkennung. Hier hiflt nur das Warten auf eine neue Firmware. Aruba, Ubiquiti und Lancom-Kunden müssen die Länderkennung lediglich korrigieren. Eine Einstellung „Default“ oder „Europa“ führt hier ebenfalls zum besagten Problem, das Problem ist schon fast behoben, wenn Deutschland gewählt wird. Wer Baumarkt-Plasten (TP-Link/D-Link) oder TR069 Kram (Vodafone Easybox oder Telekom Speedport) vom Provider einsetzt, muss hier erst einmal warten, bis neue Firmware bereitgestellt wird.
Länderkennung, mit gedrückter ALT-Taste schnell erkennbar: Steht hier „XX“, ist das Problem akut.
a) Noch kein 10.10.1 installiert:
Bei Multi-SSID/Roaming-Lösungen sollte ein neues Netzwerk bereitgestellt werden, in jenem folgende Funktionen zwingend deaktiviert sind:
— Frame Aggregation
— U-APSD/WMM Powersave
— Eingrenzung der möglichen 5GHz-Kanäle auf ab Kanal 52 (DFS) aufwärts
Hinweis: Das Entfernen der Frame Aggregation sorgt für eine deutliche Performance-Verschlechterung der Clients in der entsprechenden SSID. In sofern sollte für Yosemite-Clients eine weitere, logische SSID geöffnet werden, damit andere Anwender dadurch nicht beeinträchtigt werden.
b) Update 10.10.1 über Dev-Seed geladen oder bereits verfügbar:
— Eingrenzung der möglichen 5GHz-Kanäle auf ab Kanal 52 (DFS) aufwärts
Damit sollten die Störungen behoben sein.
####
Heimplaste ist hier nicht gemeint. Ubiquiti-, und Lancom-Kunden können hier ggf. Abhilfe schaffen. Am einfachsten geht es mit Lancom. Meine Beobachtungen sehen wie folgt aus: Die Accesspoints weisen messbar (in Nagios/Check_MK) eine deutlich höhere Prozesslast aus. Teilweise bewegten sie sich sogar zu Abstürzen und kamen alle 2 Minuten neu hoch, je nachdem wie viele Anwender in der Nähe sind. Das schlimme an dieser Thematik ist, dass Yosemite-Benutzer damit die anderen Benutzer negativ beeinflussen, also gleich mal die ganze Belegschaft einer kompletten Firma (Ubiquiti). Im weiteren Verlauf dieses Artikels wird das Verhalten und die Auswirkung deutlicher. Im Labor konnte ich mir dann mal einen Accesspoint isoliert betrachten und machte das Problem schnell aus.
Ein Trace auf WLAN Aggregation für die Mac’s mit Yosemite sieht hier beispielhaft wie folgt aus:
((UPDATE:))
Im unteren Bereich des Screenshots sehe ich ein normales Verhalten von 1-2 iPhones und iPads. Im oberen Bereich sehe ich bis zur Disassociation ein MacBook Air, welches im im unteren Layer schon komplett aus dem Ruder läuft. Hierbei ist zu bemerken, dass es technisch überhaupt nicht mehr funken kann, da es nicht einmal mehr zum Fortlaufenden Handshake kommt. ((Update: Alfred erklärt im Forum, dass der Client Frame-Aggregation nur ablehnt und es deswegen nicht zum Störfall kommen sollte – Link)). Das ganze passiert jedoch schon, während man 100-200K erfolgreich gefunkt hat. Der Accesspoint neigt – sofern er schwachbrüstig ausgelegt oder mit einer Schutzfunktion ausgerüstet ist – zum Absturz.
((ENDE-UPDATE))
Die Fehlermeldung lautet (der Hotspot wird geflutet damit):
[framed_box style=“info“][WLAN-AGGREGATION] 2014/10/28 23:43:02,220 Devicetime: 2014/10/28 23:43:02,075
xWLanAggrTxHandle to xx:xx:xx:xx:xx:xx TID 6 HwBusy no BlockACK state Error
–> BlockACK negotiation failed, send as non-aggregated packet[/framed_box]
Ein Google nach Block Ack WiFi brachte mich recht zügig zum Ziel. Es muss sich bei dem sichtbaren „Problem“ um die Frame-Aggregation handeln. Sollte diese aktiv sein, sollte man das in einer Test-SSID mal deaktivieren und schauen, ob sich dann wieder was im positiven Sinne tut. Es geht vielmehr um die gleich folgenden Fehlermeldungen, die zusammen mit Frame-Aggregation den Chip wohl zum Absturz bringen können. Immerhin, das Deaktivieren der FrameAggregation half bei mir bei knapp 90% der Yosemite Clients. Hat man es deaktiviert, so geht die Prozesslast auf allen Accesspoint augenblicklich runter. Die eigentliche Ursache (Beacon-Fehler) wird dann im Trace sichtbar:
[framed_box style=“info“][WLAN-STATUS] 2014/10/29 02:11:14,637 Devicetime: 2014/10/29 02:11:15,025
WLAN-1: 2 beacon(s) not picked up (XX——-)
Tralala
LastSubmit 100, LastCleanup 184, LastStop 38491, LastStart 38487)
current modem load is 3%
BB hang detect: BB state still changing, no hang, BB panic status 0x00000000[/framed_box]
Eine Meldung, die ich zuvor nie zu Gesicht bekommen habe und ich nicht näher auf eine weitere Lösung reduzieren kann. Der Zusammenhang Beacon->Frame-Aggregation ist aus meiner (bescheidenen, unwissenden) Sicht gegeben, da erst mit dieser Funktion aktiv ein Schwachbrüstiger Mitbewerber-Hotspot zum Absturz kommt. Ich tippe mal darauf, dass Apple selbst am Treiber geschraubt hat, um die neuen Funktionen für iOS bereitzustellen. Eindämmen lässt sich das auch nicht, da die Beaconfehler von jedem Client gesendet werden und durch die Accesspoints nicht mehr zugeordnet werden können, im schlimmsten Fall quer durch alle Hotspots (gesehen bei Ubiquiti) wie ein Dominoeffekt verteilt werden. Das führt dann dazu, dass gleich mal eine ganze Firma „platt“ ist, und zwar im wahrsten Sinne des Wortes, hinsichtlich der WiFi-Versorgung. Deaktivieren der Frame-Aggregation (Ubiquiti: Packet Aggregation) hilft. Die Prozesslast geht merkbar zurück, die Clients können wieder arbeiten. Dabei ist das Genöhle der Mac-Anwender zu verschmerzen, die momentan nur mit 54M empfangen können, sie müssen halt warten, bis Apple den Treiber wieder korrigiert. Frame-Aggregation soll für eine Beschleunigung im Netz sorgen, in diesem Fall sorgt es dafür, dass mit Mac’s im Umfeld gleich alles platt ist.
Weiterhin kann (d.h. muss nicht) bei den restlichen 10%, die selbst durch die Deaktivierung der Frame-Aggregation nicht weiter kommen, folgendes helfen:
Deaktivieren von U/APSD, Deaktivieren der Funktion „Nur Unicasts übertragen, Broad- und Multicasts unterdrücken“, Deaktivieren der Funktion „Broadcast DHCP in Unicast konvertieren“. Die Frame-Aggregation ist bei intelligenten Lösungen ebenfalls in diesem Bereich zu finden.
Beispiel für eine Konfiguration mit einem WLAN-Controller:
Unter Umständen hilft vielleicht auch ein Downgrade des Accesspoints auf eine Firmware vor AC-Unterstützung. Weiterhin höre ich, dass die Bereitstellung der WiFi Frequenzbänder oberhalb von Kanal 50 helfen sollen. Sollte ein Supportmitarbeiter seitens Apple auf die Idee kommen, die „Preferences“ von Euch löschen zu lassen, deinstalliert beim Anwender vorher Software für VPN (z.B. Advanced VPN Client/NCP/usw.). Helfen tut das übrigens überhaupt nicht. Ein nackt installiertes Yosemite kommt mit 54M auf einem Lancom definitiv klar (keine Drops mehr), jedoch nicht in der alten Performance.
Ich drücke Euch die Daumen!