WLAN Roaming mit Zyxel NXC 2500 und Zyxel NWA3560-N

Nicht ganz...und nicht nur Meru oder Extricom. Alle Controller basierten WLANs supporten das mehr oder weniger. Bei Motorola, Cisco und auch Aruba ist das Client Roaming ebenfalls Controller basiert und wird nicht vom Client initiiert.
Bei nicht Controller WLANs oder welchen mit "Spar Controllern" über einen dedizierten AP geht das aber nicht. Dort entscheidet immer der Client. Und dessen Roaming ist mehr als mies.
Client Roaming kann auch niemals mit verschlüsselten Verbindungen umgehen. Bei Controller WLANs findet eine sog. Preauthentication statt am zu roamenden Ziel AP um so hitless die Verbindung umschalten zu können.
Normale APs können sowas nicht und das bedingt dann bei einem Client basierten Roaming immer den vollständigen Abbruch der verschlüsselten Verbindung und dem kompletten Neuaufbau mit Schlüsseltausch.
Fazit: Ohne intelligenten Controller ist das nicht machbar.

Wir müssen 2 Dinge unterscheiden:
a) ob der Controller das Wechseln des Accesspoints initieren oder gar selbst durchführen kann und
b) ob der Client am neuen Accesspoint noch einmal eine Authentifizierung durchführen muss bzw. ob er sie zumindest "abkürzen" kann

Bzgl. Punkt a) habe ich mich oben vielleicht mit meinem einleitenden Satz etwas unglücklich ausgedrückt. Der NXC kann durchaus den Client veranlassen, die Funkzelle zu verlassen. So z.B. im Rahmen des Bandsteerings (Bevorzugung des 5 GHz-Frequenzbandes) oder beim Loadbalancing (Entscheidung nach aktueller Last oder anhand der Clientanzahl). Oder wie bereits dargelegt aufgrund der Unterschreitung einer definierten Empfangsfeldstärke. Andere Hersteller mögen hierfür differenziertere Algorithmen mit weiteren Kriterien implementiert haben (bei Zyxel ist es auch nicht ganz so eindimensional: so kann etwa berücksichtigt werden, ob der Client gerade Daten überträgt). Jedoch ist es nach meinem (bisherigen) Kenntnisstand auch bei anderen Microzellensystemen so, dass der Controller lediglich den Client rauskickt und dadurch indirekt den AP-Wechsel initiiert - nicht jedoch eine für den Client unsichtbare Übergabe an einen anderen AP durch den Controller erfolgt. Sollte ich mich irren, lerne ich selbstverständlich gerne dazu. Man kann schließlich nicht alles wissen und schon gar nicht selbst getestet haben.
Wenn der Client also gezwungener Maßen den Accesspoint wechselt ist die Frage, wie lange ein Neuverbinden mit dem nächsten Accesspoint dauert. Hierfür ist von entscheidender Bedeutung, wie lange die Authentifizierung dauert (Punkt b). Meines Wissens gibt es keine (standardisierten) Verfahren, die die Reauthentifizierung komplett unnötig machen, sondern lediglich solche, die diese deutlich verkürzen. Der NXC von Zyxel unterstützt hier das PMK-Caching (für schnelles Zurückwechseln auf einen zuvor verwendeten AP) als auch das von Dir bereits genannte Preauthentication (für schnelleres Wechseln auf einen zuvor nicht genutzten AP). Beides ist aber nach meinem bisherigen Kenntnisstand zum einen nur bei Einsatz von 802.1x relevant und zum anderen muss beides auch vom Client unterstützt werden. Tut er dies nicht, dauert das Wechseln des APs entsprechend lange. Ein schnelles Roaming ist hier also nicht nur von der Intelligenz des Controllers abhängig, sondern sehrwohl auch vom Client.
Bei den Singlechannelsystemen von Meru oder Extricom ist die Sache anders: hier merkt der Client gar nicht, dass er den Accesspoint wechselt, da weder die BSSID noch der Kanal gewechselt wird. Der Client glaubt weiterhin, mit dem gleichen Accesspoint zu sprechen. Die Entscheidung, mit welchem physischen AP der Client tatsächlich spricht, trifft ausschließlich der Controller. Anders als bei Microzellensystemen ist man daher beim Roaming in Singlechannelsystemen nicht auf ein Wohlverhalten des Clients angewiesen.

Aber kommen wir nochmal zur Ausgangsfrage zurück: Wenn die Macbooks nicht nur sich ewig an dem schwächeren AP festhalten, sondern auch bei einem kompletten Abreißen der Verbindung kein Neuverbinden zu einem anderen verfügbaren AP durchführen, dann haben die Geräte/Treiber vielleicht wirklich ein Implementierungs- oder Konfigurationsproblem. Meiner Erfahrung nach funktioniert selbst ein rein clientbasiertes Roaming bei korrekter Zellplanung und sinnvoller Einstellung der Grenzwerte an den APs in der Regel durchaus befriedigend.

Gruß
sk

Besser hätte man es nicht erklären können
Es gab mal ein standardtisiertes Verfahren mit IEEE 802.11f was aber kein Hersteller implemntiert hat und zudem wurde dieser Standard auch wieder zurückgezogen. Jeder Hersteller macht da jetzt was Eigenes.
Die Preauthentication, sofern Hersteller das im Controller in ihrem Roaming Verfahren überhaupt implementiert haben, hat nichts oder nur bedingt was mit 802.1x zu tun, denn proprietäre Verfahren die ja hier zum Einsatz kommen sind davon abgekoppelt.
Erst in jüngerer Zeit gibt es einen Standard der dies in Verbindung mit Client based Reauthentication bei 802.1x authentisierten WLANs regelt. Proprietär, ohne .1x, funktioniert das aber auch in Controllern von Cisco, Motorola und Aruba z.B.
Solche Verfahren musste es geben bei einzelnen Herstellern, da diese auch das "hitless" Roaming mit Hersteller unterschiedlichen VoWLAN Geräten bewerben oder sicherstellen. Sprich also das mobile WLAN Telefone unterbrechungsfrei von einer Zelle in die andere durchgereicht werden wie es bei GSM/UMTS der Fall ist.
Ein wesentliches Feature um Voice Devices im WLAN Umfeld verlässlich zu betreiben ohne längere Audio aussetze bei der Sprachübertragung !
Bei Meru und anderen die Single Channel / Virtual Cell Verfahren einsetzen entfällt sowas natürlich. In der Beziehung sind solche Roaming Funktionen dort quasi per se im System schon vorhanden, das ist richtig.
Zur Ausgangsfrage:
Diveres MacBooks und auch das Air roamen hier clientbasiert an Cisco APs (ohne Controller) und auch Airports vollkommen problemlos. Was den Datenverkehr anbetrifft merkt man den Zellenwechsel nichtmal groß.
Gerade Macs machen das vorbildlich weil sie eben nicht so rudimentäre und schlampig programmierte Treiber haben wie China oder Taiwan Billighardware.