Loesungen und Stand zur "WLAN Problematik"

[Daniel Baumann]

Hallo zusammen

Nachdem wir in den vergangen Wochen uns primaer um die Beseitigung der
dringensten Notfallarbeiten bei Firewall und Hardware bei Moodle und
Basis-Diensten gekuemmert haben, gehen wir jetzt weiter zu WLAN fuer
welches wir im Rahmen der organisatorischen Anpassungen per 1. Mai die
Verantwortung uebernommen haben.


1. Kurzfassung
==============

Wir haben in der letzten Zeit vermehrt Problemmeldungen bzgl. WLAN
erhalten. Diese lassen sich auf vier jeweils voneinander
unterschiedliche Problemkreise zurueckfuehren:

  * ab Mitte Maerz: "Verbindungsaufbau Android 10":

    - betrifft nur wenige Geraete-Modelle und nicht alle Android 10
      Geraete (Inkompatibilitaet in der Implementierung von WPA3
      zwischen Cisco und bisher 2 Handy-Herstellern)
    - bliebt schwierig, entweder schliesst man die einen oder die
      anderen aus
    - Problemloesung gehen wir naechste Woche an und werden u.U.
      WPA3 bis auf Weiteres abschalten muessen und erst nach
      vorgaengigen Kompatibilitaetstests wieder anschalten koennen

  * ab Ende April: "Signalstaerke HAFL Wohnheim":

    - alle WLAN-Netze (SSIDs) betroffen
    - nur Standort HAFL Wohnheim in Zollikofen betroffen
    - geloest seit 12. Mai durch Reduzierung der maximalen
      Kanalbreite pro Client

  * seit 12. Mai: "Allgemeine Verbindungsabbrueche/Signalqualitaet"

    - vorallem bei MS-Teams und anderer Video-Telefonie gibt es
      an allen Standorten BFH-weit immer wieder Verbindungsabbrueche
    - es sind nur die WLAN-Netze bfh, eduroam und bfh-things betroffen
    - werden wir heute loesen durch Abschalten von "Langsame Datenrate
      erlauben"

  * seit 27. Mai: "bfh-open funktioniert nicht"

     - ist noch auf TODO, sind wir noch nicht dazu gekommen. Hat im
       Rahmen aller anderen Notfaelle, weil es "nur" das Gaestenetz
       Betrifft, die tiefste Prioritaet innerhalb der Prio 1 Dinge
     - wir werden morgen Samstag das Problem anschauen und loesen


2. Hintergrund
==============

2.1 "Verbindungsaufbau Android 10"
----------------------------------

  * Bei WLAN koennen die Netzwerkpakete entweder unverschluesselt oder
    verschluesselt uebertragen werden. Zur Verschluesselung wurde
    frueher WEP, heute WPA benutzt und findet zwischen Layer 1 und Layer
    2 statt.

  * WPA gibts in mehreren Versionen, die meisten verwenden noch WPA2
    welches aus Security Gruenden eigentlich nicht mehr verwendet werden
    sollte. WPA3 ist generell noch kaum verbreitet, weder bei Clients
    (erst ab Android 10) noch bei Infrastruktur.

  * WPA gibts in mehreren Varianten, Pre Shared Key (PSK) das man als
    "wie lautet das Passwort fuers Wifi" aus dem Heimbereich kennt und
    Enterprise bei welchem man sich inviduell mit User und Passwort
    authentisieren muss. Die "bfh" und "eduroam" Netze setzen auf
    WPA2-Enteprise.

  * Innerhalb einer jeden WPA Variante gibts dann noch unterschiedliche
    kryptographische Algorithmen und Kombinationen fuer die
    Verschluesselung/Uebertragung der Login-Daten und der danach
    folgenden Netzwerkpakete. Allen gemeinsam ist, dass bei WPA der
    Client sich mit dem Accesspoint ueber die jeweiligen verfuegbaren
    Parameter zuerst austauschen und ggf. einigen muss, damit eine
    Netzwerk-Verbindung zustandekommt.

  * Dazu werden sogenannte Beacons vom Client versendet, auf die ein
    Accesspoint antwortet und so den initialen Verbindungsaufbau zur
    Authentisierung ausloest. Versendet der Client keine Beacons,
    passiert nichts und der Client wird sich nie verbinden koennen.

  * Da WPA3 noch relativ neu ist, ist die Implementierung davon sowohl
    in den Geraeten wie auch in der Infrastruktur noch "im Fluss" und
    es werden laufend Bugs gefunden und geschlossen.

  * Fuer Android 10 hat Google WPA2 und WPA3 Support als zwingend
    definiert. Trotzdem gibt es zwei Hersteller (Xiaomi und Nokia),
    bei welchen *einzelne* Modelle kein WPA2 (dafuer aber WEP, sic!)
    unterstuetzen, oder "falsche" Beacons aussenden, so dass je nach je
    eine WPA2 oder WPA3 Initialisierung nicht ausgeloest wird. Aufgrund
    des Designs von WPA ist, fuer diese Problematik, konzeptionell ein
    Workaround auf Accesspoint-Seite ausgeschlossen.

  * Die Situation koennte aus Sicht Infrastruktur nicht schlimmer sein,
    da bei z.B. Xiaomi neuere Steppings *desselben* Modells mit Bugfixes
    ausgestattet wurden, welche aelter Steppings nicht haben und auch
    nicht per Update erhalten. D.h. fuer User bedeutet das, dass
    Kollegen mit dem scheinbar identischem Telefon eine Verbindung
    haben koennen, man selber aber nicht, was nicht offensichtlich und
    fuer alle frustrierend ist.

    NB: Bei Nokia sind auch unterschiedliche Modelle betroffen,
    allerdings gibt es jeweils zeitnahe Updates so dass alle Steppings
    eines Modelles gleichauf sind, sofern die User diese einspielen.

  * Es gibt hunderte Berichte im Internet zu diesem Thema, es gibt ganz
    viele "hilfreiche" Tipps auf Kombination die mit einzelnen
    Geraeten/Steppings funktionieren und mit anderen nicht (z.B. soll
    angeblich AES statt TKIP helfen, nicht aber AES-GCM was erstmal
    keinen Sinn ergibt; bei wieder anderen funktioniert offenbar
    wenn man Bluetooth waehrend des WLAN-Verbindens ausschaltet...).

    Da einige dieser "hilfreichen" Tipps Parameter auf Infrastruktur-
    Seite betreffen die global gelten, werden wir zum Wohle aller nicht
    leichtfertig und uebereilt Settings aendern und ggf. fuer alle das
    Netz unbenutzbar machen, auch wenn das bedeutet dass Personen mit
    bestimmten Xiaomi oder Nokia Geraeten kein WLAN Zugriff haben.

  * Wir werden uns WPA3 im Zusammenhang mit Android 10 naechste Woche
    widmen, halten euch auf dem Laufenden und bedanken uns bei den
    (wenigen) Betroffenen fuer eure Geduld.

  * Als Workaround kann auf "bfh-open" ausgewichen werden, welches
    weil Gaestenetz kein WPA macht sondern auf "Layer 1.5"
    unverschluesselt ist (im HTTPS Zeitalter weniger relevant als auch
    schon). Dieses bietet allerdings "nur" Internet-Zugang
    und kein Zugriff auf Dienste im internen BFH-Netz.


2.2 "Signalstaerke HAFL Wohnheim"
---------------------------------

  * WLAN nach IEEE 802.11 gibt es in drei Frequenzbereichen:
    2.4GHz, 5GHz und 60GHz. Bei uns stehen 2.4GHz und 5GHz zur
    Verfuegung, wovon hauptsaechlich das 5GHz Band benutzt wird.
    Dabei sind Datenraten bei uns von bis zu 600 Mbit/s (802.11n) und
    936 Mbit/s (802.11ac) nutzbar.

  * WLAN ist ein shared Medium, deshalb wird der jeweilige
    Frequenzbereich in Kanaele eingeteilt. Im 5GHz Bereich koennen diese
    20, 40, 80 oder sogar 160MHz breit sein. Je breiter der Kanal den
    ein Client benutzen kann, umso hoeher die Bandbreite.
    Theoretisch waere so bei 802.11ac eine maximale Bandbreite von
    3466.7 Mbit/s herstellerunabhaengig erreichbar (geht bei uns
    allerdings nicht, weil die Accesspoints grundsaetzlich nur mit
    1Gbit/s angeschlossen sind).

  * Im HAFL Wohnheim haben wir die Situation, dass im Vergleich zur
    Rest-BFH ueberdurchschnittlich viele und aktuelle(!) WLAN-Gerate auf
    engstem Raum vorhanden sind. Jedes Geraet versucht, zu Recht und
    je neuer je aggressiver, fuer sich beim Verbindungsaufbau mit dem
    Accesspoint den moeglichst breitesten Kanal zu belegen (NB: auch
    wenn sies gar nicht benutzen/sinnvoll ist wie z.B. eigene
    Drucker von Studierenden, welche 24/7 mit dem WLAN verbunden sind
    damit man "selten" mal vom Handy/Notebook ohne Kabel drucken kann).
    Ein einmal belegter Kanal ist solange das Geraet mit dem WLAN
    verbunden ist, besetzt und kann nicht von einem anderen Geraet
    benutzt werden.

  * Bisher waren bei uns pro Client bis zu 80MHz Kanalbreite moeglich.
    Im Wohnheim hat das aufgrund der vielen Geraete dazu gefuehrt, dass
    wer zu "spaet" kam keine oder nur sehr wenig Bandbreite mehr
    erhalten konnte.

  * Durch ein Reduzieren der maximalen durch den Client belegbaren
    Kanalbreite von 80MHz auf 40MHz am 12. Mai kann eine hoehere Anzahl
    von Geraeten pro Accesspoint bedient werden. Diese Reduzierung gilt
    Global und macht das gesamte WLAN-Netz besser wo besonders viele
    WLAN-Geraete dicht auf engem Raum sind, ueberall sonst
    schadet/aendert es nichts. Dadurch werden insbesondere auch bei
    Online-Pruefungen die Vorort durchgefuehrt werden (Stichwort Moodle
    oder Safe Exam Browser) nicht mehr zur besonderen Herausforderung
    wie das bisher oft der Fall war.

  * Weil, unabhaengig von der Kanalbreite, unterschiedliche Modulationen
    fuer die Datenuebertragung verwendet werden koennen, sinkt die bei
    40MHz Kanaelen maximal zur Verfuegung stehende Bandbreite
    nur geringfuegig von bei uns 936 Mbit/s auf 800 Mbit/s (vergl.
    https://en.wikipedia.org/wiki/IEEE_802.11ac#Data_rates_and_speed).

  * Uebrigens: Zwar hat das 5GHz deutlich mehr Kanaele zur Verfuegung
    als das 2.4GHz Band, allerdings wird die moeglich Anzahl Kanaele
    durch zwei Gruende massiv limitiert:
    - regional unterschiedliche regulatorische Bestimmungen erlauben
      generell nur das Benutzen eines Teilbereiches
    - grundsaetzlich sind nur die ersten 48 Kanaele ueberhaupt fuer WLAN
      exklusiv reserviert. Kanal 49 bis 165(!) ueberschneitet sich mit
      Wetterradar und kann nur benutzt werden, wenn ein aufwaendiges
      "Kollisionsverhinderungsprotokoll" umgesetzt wird (dabei muss
      jeder Client periodisch pruefen, ob der gewuenschte Kanal
      zufaellig vorort und in dem Moment gerade durch einen Wetterradar
      benutzt wird und falls ja, diesen sofort freigeben, Stichwort
      Dynamic Frequency Selection (DFS)). Da die meisten Hersteller in
      ihren WLAN-Geraeten dies aus Komplexitaets- oder schlicht
      Kostengruenden nicht implementieren, sind also nur weniger als ein
      Drittel(!) aller Kanaele ueberhaupt benutzbar.

  * Der Vorschlag zur Reduzierung der Kanalbreite kam von einem
    Mitarbeiter unseres Externen Partner der das Cisco Netz an der BFH
    betreut, besten Dank dafuer.

  * Seit dieser Reduzierung am 12.5. gibt es keine bei uns bekannten
    WLAN-Probleme mehr im HAFL Wohnheim.


2.3 "Allgemeine Verbindungsabbrueche/Signalqualitaet"
-----------------------------------------------------

  * Die BFH hat wie fuer die Schweiz typisch was WLAN angeht,
    relativ moderne und ueberwiegend einheitliche Client-Hardware im
    Einsatz. D.h. praktisch alle Notebooks benutzen das 5GHz Band
    und machen entweder 802.11n oder 802.11ac.

  * Neben der oben erwaehnten Kanalbreite und Modulation, ist beim 5GHz
    Frequenzband zusaetzlich auch noch die Anzahl der verwendeten
    Antennen massgeblich fuer die zur Verfuegung stehende Bandbreite.

  * Je mehr Antennen gleichzeitig benutzt werden koennen (bis zu 4 mit
    jeweils einem Stream welche hardware-technisch zu einer einzigen
    Verbindungen auf Layer 1 logisch zusammengefasst werden), umso mehr
    Bandbreite ist nutzbar.

  * Je besser die Verbindung vom Client zum Accesspoint ist (sprich:
    je naeher und mit weniger raeumlichen Hindernissen wie
    Waenden/Baeumen sich der Client zum Accesspoint befindet), umso mehr
    Antennen/Streams koennen benutzt werden.

  * Je schlechter die Verbindung (Distanz/Hindernisse), umso weniger
    Antennen koennen benutzt werden und umso enger sind auch die
    Kanalbreiten die benutzt werden koennen. Dadurch reduziert sich
    automatisch die Bandbreite die benutzt werden kann.

  * Beim Design von WLAN Netzen muss man sich zwischen zwei Paradigmen
    entscheiden:

    1. entweder setzt man auf maximale Reichweite einzelner
       Accesspoints und erlaubt auch, dass von "weit weg" noch langsame
       Verbindungen aufgebaut werden koennen:

       -> Vorteil: braucht insgesamt weniger Accesspoints

       -> Nachteil: es sind auch "schlechte" Verbindungen moeglich

    2. oder man setzt auf maximale Bandbreite:

       -> Vorteil: es sind nur "schnelle" Verbindungen ab einer gewissen
          Qualitaet moeglich oder gar keine, d.h. Nutzende haben ein
          diskretes Verhalten: entweder die Verbindung zum Accesspoint
          klappt und ist gut, oder man man hat gar keine Verbindung und
          man muss naeher an den Accesspoint ran

       -> Nachteil: es braucht insgesamt mehr Accesspoints damit WLAN
          flaechendeckend zur Verfuegung steht
          ("Abdeckungsproblem")

  * Wir gehen davon aus, dass beim BFH-WLAN Netz man auf die 2. Variante
    fuer maximale Bandbreite gesetzt hat (was unserer Meinung die
    richtige Variante ist; die maximale Reichweite-Variante empfiehlt
    sich primaer fuer den Heimbereich, nicht fuer den professionellen
    Einsatz).

  * Der Unterschied zwischen Variante 1 und Variante 2 wird durch eine
    Einstellung von "Langsamere Datenraten erlauben: ja/nein" Setting
    auf den Cisco Wireless-Controllern gesteuert. Werden langsame
    Datenraten von 6.5 resp. 13 Mbit/s erlaubt (enspricht 1 Stream mit
    tiefster Modulation und 40Mhz resp. 80Mhz Kanalbreite), sind wir im
    Variante 1 Modus. Bisher war dieses Setting auf "nein", d.h.
    langsame Datenraten waren *nicht* erlaubt.

    NB: 6.5 resp. 13 Mbit/s erlauben heisst nicht, dass dann "nur"
    diese Datenraten zur mindestens zur Verfuegung stehen muessen,
    dies betrifft nur die Anzahl Streams, Kanalbreite und Modulation
    Kombination welche eine *maximal* Bandbreite von 6.5 resp. 13 Mbit/s
    haben. D.h. wenn eine solche Kombination von einem Client
    ausgewaehlt wird weil anderst keine Verbindung mehr moeglich waere,
    sind in der Regel diese maximalen Bandbreiten trotzdem nicht
    erreichbar und ein Client bewegt sich zwischen 0 und 1 Mbit/s
    (spich: reicht knapp zum Versenden von einfachen E-Mails, mehr geht
    nicht in sinnvoll).

  * Am 12.5. wurde durch einen Mitarbeiter unseres Externen Partner der
    das Cisco Netz betreibt, auf den Wireless Controllern dieses Setting
    angeschaltet (d.h. langsame Datenraten waren neu erlaubt). Seither
    haben wir Probleme ueberall im WLAN-Netz.

    Schlimmer noch: durch diese Aenderung verbinden sich WLAN-Geraete
    auch mit entfernten/schlecht erreichbaren Accesspoints und bleiben
    dann, aufgrund eines anderen Settings das aggressiveres Roaming
    unterdrueckt (Review Roaming Settings steht fuer ein andermal an),
    auf diesen "schlechten" Accesspoint auch wenn durch Verschieben des
    Geraetes ein besser erreichbarer Accesspoint verfuegbar waere. Dies
    hat dazu gefuehrt dass bei Bandbreiten-sensitiven Diensten wie
    MS-Teams und generell Video-Telefonie dies Verbindungsabbruechen und
    schlechte Video/Audio Qualitaet zur Folge hat.

  * Diese Aenderung wurde unter dem Titel "wir optimieren mal euer
    WLAN-Netz und setzen allgemeine Best Practise um" stillschweigend
    durchgefuehrt, wovon uns nur die oben erwaehnte Kanalbreiten-
    Reduzierung kommuniziert wurde. Ueber alle anderen Aenderungen
    wurden wir nicht informiert (ja, im Nachhinein haetten wir
    micro-manageing-maessig nachfragen muessen und dem "handwaveing"
    nicht vertrauen duerfen - das ist mein persoenlicher Fehler, sorry).

  * Durch Verlangen aller Konfigurationsdateien und dem manuellen Review
    aller Aenderungen haben wir gestern vormittag dies entdeckt. Wir
    werden diese Einstellung heute in einem ausserordentlichen
    Wartungsfenster umgehend rueckgaengig machen lassen (Groessenbereich
    5min WLAN Unterbruch im Zeitraum voraussichtlich 12:00 bis 13:00),
    damit sofort wieder wie gewohnt und ueberall ein gutes und stabiles
    WLAN-Netz zur Verfuegung steht.

  * Aufgrund der Notfallarbeiten an Firewall, Moodle und Basis-Dienste
    Hardware in den vergangen Wochen welche wir zusaetzlich zum vollen
    Pensum in Ueberstunden umgesetzt haben, konnten wir uns erst jetzt
    dem Thema WLAN annehmen. Wir entschuldigen uns fuer die daraus
    entstandenen Umstaende und danken fuer euer Verstaendnis.

  * Uebrigens: der Wechsel auf "eduroam" welches in den letzten Tagen
    von einigen Seiten als Workaround empfohlen wurde, hat je nach
    je darum geholfen, weil dadurch ein Client sich neu mit einem
    (inzwischen) "besser erreichbaren" Accesspoint verbunden hat und das
    "Anti-Roaming Feature" unterbrochen hat. Ein Neuverbinden mit dem
    "bfh" Netz haette allerdings den selben Effekt gehabt.

  * Last but not least, Lessons learned: Micro-Managing des Externen
    Partners notwendig.

Gruesse,
Daniel

-- 
Berner Fachhochschule / Bern University of Applied Sciences
Services / IT-Services
Daniel Baumann
Teamleiter Linux & Infrastructure Services
___________________________________________________________
Dammweg 3, CH-3013 Bern
Telefon direkt +41 31 848 48 22
Telefon Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://bfh.ch
https://bfh.science