Zur Visualisierung von umfangreicheren technischen Umständen benötigen wir Menschen oft Grafiken und Diagramme. Im WLAN-Umfeld aber auch anderswo setzt man sogenannte Heatmaps ein, die eine Skalierung von unterschiedlichen (Mess-)Werten in einer Farbskala auf einer Kartenbasis darstellen. Heatmaps sind also kurzum Skalendarstellungen auf Plänen bzw. Karten.
Warum sind Heatmaps nützlich?
Um die Signalstärke, auftretenden Störungen und eine grafische Simulation der Netzausbreitung darzustellen, sind Heatmaps ein gutes Hilfsmittel. Sie stellen simulierte (oder je nach eingesetzter Hardware auch gemessene) Werte grafisch dar, um dem Nutzer oder Administrator zu zeigen und wo ggf. Probleme auftreten können, wo wie nachgebessert werden kann.
Heatmaps unter UniFi stellen simulierte Werte grafisch dar. Es gibt Hersteller, die tatsächliche Live-Daten zur Ausbreitung nutzen, dafür muss allerdings je Frequenzband mindestens ein Radio dauerhaft im sogenannten Survey- bzw. Monitor-Mode laufen. In diesem Modus wird laufend die Funkumgebung überwacht, aber vom entsprechenden AP keine eigenen Bacons verschickt, die z.B. das Vorhandensein einer SSiD propagieren.
Ein grober Richtwert zur Optimierung
Für die Optimierung vom bestehenden Problemen kann eine solche Heatmap sicher aufschlussreich sein – sie deckt aber lange nicht alle Parameter ab, die bei einer fundierten Wireless-Implementierung von Relevanz sind. So gibt die UniFi-Heatmap lediglich Aufschluss über Signalstärke im 2,4 GHz- und 5 GHz-Band. Datenrate, SNR oder etwa Störeinflüsse (Co-Channelinterferenzen, Radar, Mikrowellenstrahlung…) werden nicht erfasst, was ein sehr vereinfachtes aber nicht vollständiges Bild der Umgebung erzeugt.
Viele Nutzer oder WLAN-Betreiber kennen es von zuhause, vielleicht auch aus kleineren Gastronomien oder Ladenlokalen: Das W-LAN war sofort startklar, läuft seit Tag 1 – aber irgendwie wie ein Sack Mehl. Das kann natürlich etliche Ursachen haben, einer möglichen Ursache gehe ich in diesem Post etwas weiter auf den Grund. Keinesfalls möchte ich hier in ein Bashing verfallen, die Einstellungen, die Hersteller von Werk aus treffen, haben ihre Berechtigung – und diese Einstellungen treffen die meisten Hersteller für ein Erst-Setup. Es wird lediglich aufgrund der hohen Verbreitung im deutschsprachigen Raum in Heimnetzen die Produktreihe der Fritzboxen des Herstellers AVM zum Vergleich herangezogen. Das Phänomen erstreckt sich aber auch über alle anderen Hersteller von WLAN-Geräten.
Ihr WLAN in 3… 2… 1… Fertig!
Toller Slogan! Wir wünschen uns doch alle, das etwas quasi sofort funktioniert, oder? Viele Hersteller im Consumer-Umfeld werben mit solchen oder vergleichbaren Slogans um ihre intuitiven und einfach designten Produkte, die selbst Kinder eingerichtet bekommen. Dass Technologie mit fortschreitender Entwicklung nie einfacher, sondern im Unterbau immer komplexer wird, wird dem Anwender hier nicht verschwiegen, aber eine Schein-Einfachheit suggeriert. Respekt an die Hersteller, die es immer wieder schaffen, komplexe Technologie anwenderfreundlich zu gestalten!
Kanaleinstellungen, trotz Einfachheit beachten
Auch wenn es praktisch scheint, man sich mit der Materie nicht auseinandersetzen muss – bitte die Nutzung der Autokanalwahl durch den AP oder WLAN-Router inaktiv lassen und Kanäle nach einem Blick auf genutzte Kanäle in 2,4 GHz und 5 GHz zumindest in hochfrequentierten Regionen statisch zuweisen – oder nebst der Autokanalwahl auch das automatische Powermanagement des Radios aktiv setzen. Ansonsten entsteht das – wie ich es gern nenne – Fritzbox-Phänomen.
Das Fritzbox-Phänomen
Durch die Anforderung, dass es nach dem Start möglichst leicht “einfach funktioniert” stehen die meisten SoHo-WLAN-Systeme (darunter auch Fritzboxen von AVM) auf “Autokanal”. Treffen sich mehrere Fritzboxen in der Nachbarschaft, findet hier allerdings ein regelrechtes Channel-Hopping statt, da immer nach dem “aktuell besten Kanal” gesucht wird. Für ein Erst-Setup ist das toll, danach allerdings äußerst nervig, wenn zu viele Geräte mit diesen Settings aufeinandertreffen. Denn immer wenn ein neuer “aktuell besserer” Kanal gesucht, gefunden und vom Access Point oder Router dahin gewechselt wird, muss das Radio auf diesen Kanal eingestellt werden. Man kann sich das sinnbildlich vorstellen, wie das Umstecken eines Kabels von der einen in die andere Steckdose oder vom einen in den anderen Port. Die laufende Verbindung ist zeitweise – wenn auch kurz – unterbrochen. Aber jedes Mal, wenn ein neuer Kanal gesucht und vom Access Point verbunden wird.
Kanalansicht einer Fritzbox von AVM (Live)
2,4 GHz-Kanalauswahl einer AVM Fritzbox
5 GHz-Kanalauswahl einer AVM-Fritzbox
Bilderstrecke für Kanalzuweisungen an einer Fritzbox des Herstellers AVM
Enterprise-WiFi vs. Consumer-WiFi
Im WLAN-Umfeld gibt es mittlerweile natürlich auch einige Systeme, die über eine controller- oder cloudbasierte gemeinsame Verwaltung verfügen. Diese Systeme können mittlerweile auch gut mit Autokanaleinstellungen untereinander umgehen, allerdings wird hier deutlich mehr als der Kanal betrachtet. Man analysiert meist in Enterprise-Umgebungen ebenfalls Paketlaufzeiten, Signalstärke, mögliche Bandbreite und reellen Datendurchsatz, sowie weitere Störfaktoren und die aufgewendete Energie. In einem solch komplexen System ist es durchaus in vielen Fällen sinnig, Einstellungen auf “Auto” zu stellen – denn hier kann man z.B. auch eingrenzen, welche Kanäle z.B. überhaupt dafür genutzt werden sollen, um sogenannte Co-Channel-Interferenzen zu vermeiden. Da dies in Heimnetzwerken meist zu weit führen würde, sind die Systeme für den Heimgebrauch hier meist einfacher gestrickt, nutzen weniger Metriken, um Entscheidungen zum Kanalwechsel oder dem Roaming von einem zum anderen Gerät zu treffen. Das macht die Systeme nicht unbedingt per se schlechter, aber auch wenn sie vieles simpel darstellen, sollte man sich beizeiten mal mit einzelnen Funktionen und Einstellungsoptionen auseinandersetzen. Ob das nun die einzelne Einstellung ist, die die Umgebung viel performanter macht, hängt aber wiederum von vielen Faktoren ab. Nichtsdestotrotz bitte ich jeden WLAN-Betreiber vor allem in Ballungsgebieten, die Einstellungen zu prüfen.
Ubiquiti brachte Ende 2019 den Access Point FlexHD heraus, der mit seiner Coladosenform sicher etwas einfacher in das ein oder andere Wohn- oder Arbeitszimmer passt als die typischen Ubiquiti-Ufos der AC-Reihe. Zudem kommt der Winzling mit dem gleichen Chipsatz wie der UniFi AP nanoHD (siehe Affiliate-Link: https://amzn.to/2zEkslx), der bereits der zweiten Generation der IEEE 802.11ac-Geräte – oder Neudeutsch WiFi5-Geräte.
Was die Abmessungen angeht: Ich war erstaunt, wie viel kleiner der AP im Gegensatz zum ca. 4 Jahre älteren AP AC Pro ausgefallen ist! Die genauen Maße sind dem Datenblatt zu entnehmen.
Ubiquitis Größenvergleich des FlexHD mit 0,33l-Coladose Quelle: https://unifi-flexhd.ui.com
Um die Performance einer Netzwerkstrecke zu messen gibt es viele Möglichkeiten. Eine derer – und aus meiner Sicht die verlässlichste und gleichzeitig einheitlichste Methode – möchte ich heute vorstellen. iperf3 ist ein Open Source-Tool, was auf nahezu jedem Betriebssystem lauffähig und daher sehr universell einsetzbar ist. Zudem bietet es einige Konfigurationsoptionen, die viele Szenarien abdecken.
Um einen einfachen Test zu definierten Servern im Web zu starten, kann man sich vorerst ohne einen eigenen Server aufzusetzen bei den frei verfügbaren Servern ausprobieren. Diese finden sich hier.
Mit dem folgenden Befehl kann man bereits mit iperf3 im Clientmodus testen. Es können bei Bedarf weitere Parameter angegeben werden. Beim Windows-Client muss ggf. die Dateiendung “.exe” nach iperf3 ergänzt werden.
iperf3 -c [iPerf-Serveradresse]
Man sollte dabei allerdings bedenken, dass die angegebene Bandbreite viele Hops und längere Strecken durchläuft und jedes Mal einer Momentaufnahme entspricht. Wie man im eigenen Netz per iperf
Private iperf3-Server
Wie bereits erwähnt kann es ggf. nicht zielführend sein, einen öffentlichen Server anzufragen. Warum? Möglicherweise liegt die Ursache für eine schlechte Performance nur auf einem Teilstück der Strecke – zum Beispiel bei einem ausgelasteten Switch, langsam ausgehandelten Ports oder auch an einem ausgelasteten Speichersystem oder Virtualisierungshost. Um solchen Plagegeistern auf den Zahn zu fühlen, kann auch im lokalen Netz ein iperf3-Server installiert werden und die Strecke zum Standort dessen gemessen werden.
Installation von iperf3
Die Installation kann auf nahezu jedem Betriebssystem stattfinden. Wichtig ist, dass nach Installation eingehende und ausgehende Ports (Standard: TCP/UDP 5001-5009) in der lokalen Firewall und ggf. auf dem Weg liegenden Firewall erlaubt worden sind.
Die Binaries für eine Installation finden sich hier.
Testszenario mit iperf3 auf Ubuntu (64-Bit)
In meinem Testszenario habe ich iperf3 auf einem Ubuntu-Server mit 64 Bit laufen lassen. Üblicherweise genügt eine aktuelle Installation und aktuelle Paketquellen:
Wie kommt es zur Reduzierung der physikalischen Maximalwerte? Ganz einfach! Der Betriebssystemkernel, die Netzwerkdienste und Treiber der Karten und Schnittstellen, sowie ggf. auch intern langsamere Verbindungen führen zur Absenkung der Brutto- in Nettowerte.
Ab der Version 5.11 des UniFi-Controllers ist es möglich, Device-Footprints zu hinterlegen. Bisher funktioniert dies allerdings nur manuell. Wer also bereits einen Einblick bekommen möchte, welche Geräte sich im eigenen WLAN oder LAN tummeln, kann bereits jetzt bekannte Geräte bestimmten Profilen zuordnen.
Es sind bereits einige Hersteller und Produkte eingepflegt, allerdings scheint hier noch einiges zu fehlen. Wie oft bei Neueinführungen sehen wir hier bisher einen kleinen Teil dessen, was möglich ist. Im nächsten Schritt wäre eine automatisierte Erkennung und Footprintzuweisung wünschenswert. Wir werden sehen, wie sich Ubiquiti hier weiter anstellt.
Die Möglichkeit des Device Footprinting im Netzwerk zu erhalten, finde ich spannend und durchaus interessant – für private wie dienstliche Nutzer. Wie aussagekräftig allerdings erste automatisierte Versuche – vermutlich in Betastadium – damit sein werden, ist allerdings erstmal mit Vorsicht zu beobachten.
Es ist mal wieder so weit: Mein UniFi-Controller hat Updates gefunden. Bisher war das kein Problem, allerdings scheint nun innerhalb der Repositories für die Release-Info eine Änderung passiert zu sein. Beim Konsolenaufruf des Befehls
sudo apt-get update
störte sich mein Xubuntu daran:
Get:7 http://dl.ubnt.com/unifi/debian stable InRelease [3.024 B]
Reading package lists… Done
E: Repository ‘http://dl.ubnt.com/unifi/debian stable InRelease’ changed its ‘Codename’ value from ‘unifi-5.10’ to ‘unifi-5.11’
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Man kann die Pakete trotz der Fehlermeldung mit folgendem Befehlssatz wieder laden:
sudo apt-get update --allow-releaseinfo-change
Trotz bisher immer erfolgreicher Updatevorgänge sichert vorher die aktuelle Konfiguration des UniFi-Controllers über das Webinterface, damit eine Wiederherstellung der Konfiguration leicht von der Hand geht, sollte es doch mal so richtig krachen.
