WLAN ist DER Zugangspunkt zum Internet schlechthin, viele Geräte verfügen über keine drahtgebundenen Schnittstellen mehr. In den letzten Jahren wurde WLAN zum De-facto-Standard für den Zugang von Endbenutzern zum Internet. Auch im Produktionsumfeld wird WLAN zunehmend sogar für essenzielle Kommunikationsabläufe eingesetzt. Aufgrund der lizenzfreien Nutzung dieses Frequenzspektrums und der enormen Vielfalt verschiedener Funk-Standards kommt es jedoch auch vermehrt zu Interferenzen und anderen Inkompatibilitäten. Diese zu identifizieren und zu isolieren ist technisch und fachlich sehr anspruchsvoll und erfordert außerdem typischerweise teure Messgeräte. Salzburg Research entwickelt einen kostengünstigen Prototyp, der durch intelligente Datenanalyse und -aufbereitung ein schlagkräftiges Werkzeug zur Lösung dieser Probleme sein kann.

In den letzten Jahren wurde WLAN zum De-facto-Standard für den Zugang von Endbenutzer/-innen zum Internet. Neben dem drahtlosen Zugang verfügen die meisten Verbrauchergeräte über gar keine drahtgebundene Schnittstellen mehr. Aufgrund der ständig steigenden Anzahl drahtloser Geräte und der immer noch explodierenden Menge an übertragenen Daten ist das lizenzfreie ISM-Spektrum (Industrial, Scientific and Medical Band), auf dem auch WLAN arbeitet, bereits voll belegt und leidet zunehmend an Interferenzen. Es treten immer mehr Funkprobleme auf und in Zukunft wird dies wahrscheinlich eine der Hauptursachen für mögliche Netzwerkprobleme sein.

Auf der anderen Seite ermöglichen moderne Standards eine effiziente WLAN-Übertragung mit sehr hoher Datenrate und weniger belegter Bandbreite. In den letzten Jahrzehnten hat sich der IEEE WLAN-Standard 802.11 ständig weiterentwickelt und spezialisiert, und bietet heute eine Vielzahl von Parametern, Konfigurationsmöglichkeiten sowie notwendige und optionale Funktionen. Dies ermöglicht den Einsatz von WLAN in sehr unterschiedlichen Umgebungen, vom Heimgebrauch mit 802.11ac bis hin zur mobilen Car-to-Car-Kommunikation nach 802.11p.

Durch diese Vielfalt entstehen neue Arten von Fehlfunktionen: nicht standardkonforme Implementierungen von Funktionen, Interoperabilitätsprobleme aufgrund fehlender Unterstützung optionaler Funktionen oder einfach Fehlkonfigurationen.

WLAN: Identifikation von Wireless-Problemen oft schwierig und teuer

In der Praxis ist es für Nicht-Techniker/-innen oft unmöglich, das Drahtlosproblem zu identifizieren oder einfach nur die Art des Problems einzugrenzen. Selbst für Expertinnen und Experten gibt es kaum kostengünstige Werkzeuge zur schnellen Lokalisierung von Wireless-Problemen.

Es gibt hoch spezialisierte, teure Physical-Layer-WLAN-Messgeräte auf dem Markt, die das System auf Standard- und Gesetzeskonformität analysieren. Normalerweise treten solche Probleme aber nur während des Entwicklungsprozesses von drahtlosen Geräten auf, und daher wäre ein solcher Analysator bei der Analyse einer betriebsbereiten drahtlosen Umgebung wenig hilfreich.

Aufgrund des überfüllten Spektrums sind häufig störende andere drahtlose Geräte vorhanden. Im Prinzip könnte dieses Problem durch die Verwendung eines noch teureren Spektrumanalysators aufgespürt werden. Der Nachteil dieses Ansatzes ist, dass dieses Allzweckgerät nicht darauf spezialisiert ist, WLAN-Probleme aufzuspüren, und daher vom Anwender viel Fachwissen erfordert.

Die zuvor beschriebenen Lösungen arbeiten alle auf der physikalischen Ebene. Häufig handelt es sich bei dem Drahtlosproblem eher um ein Protokollproblem auf den OSI-Schichten 2 bis 4 als um ein Problem der physikalischen Schicht (OSI-Schicht 1). Häufige Probleme sind z.B. Fehlfunktionen beim Authentisierungs-Handshake oder die Verwendung falscher Stromsparfunktionen am Endgerät.

Auch hier gibt es Allzweck-Werkzeuge, die es Expertinnen und Experten erlauben, den Netzwerkverkehr ab Schicht 2 zu sniffen. Dieser Ansatz konzentriert sich nicht auf die Identifizierung von Wireless-Problemen an sich und erfordert daher einen umfangreichen Nachbearbeitungsaufwand durch Expertinnen und Experten.

Auf der anderen Seite gibt es sehr vereinfachte WLAN-”Analyzer”-Smartphone-Apps, die Heimanwenderinnen und -anwendern helfen können, die WLAN-Kanäle zu scannen, andere Access Points und die von ihnen verwendeten Kanäle zu identifizieren und einige Konfigurationsdetails anzuzeigen. Diese Apps können jedoch nur helfen, sehr grundlegende Probleme zu finden, z.B. das falsche Frequenzband ist eingestellt oder es wird überhaupt kein WLAN-Signal empfangen.

WLAN-Probleme identifizieren

Der WLAN-Monitor von Salzburg Research soll die große Lücke zwischen teuren und komplexen Expertentools und einfachen Endbenutzeranwendungen schließen. Der WLAN-Monitor basiert vollständig auf preiswerter Standard-Hardware und senkt damit die Hürde der Anschaffung drastisch.

Endbenutzer haben in der Regel keine speziellen WLAN-Kenntnisse, und selbst in der IT-Abteilung eines Unternehmens gibt es meist keine dedizierten WLAN-Expert/-innen. Dieser WLAN-Monitor erlaubt, die Messlösung rasch und mit nur geringen erforderlichen Kenntnissen, über die optimale räumliche Platzierung, einzusetzen. Dann beginnt der Monitor ohne weitere Benutzerkonfiguration oder sonstige Interaktion
selbstständig mit der Messung und Analyse. Ein Echtzeit-Dashboard ist über einen Webbrowser zugänglich und ermöglicht Einblicke in relevante WLAN-Parameter, wie z.B. die Frequenznutzung, und zeigt problematische Zustände sofort an.

Die variable Granularität der Analyse ermöglicht es den Expert/-innen jedoch auch, sich tiefer in komplexere Wireless-Probleme zu einzuarbeiten, unterstützt den Techniker jedoch stets, indem nur die relevanten Informationen aus den überwachten Daten extrahiert werden. Aufgrund ihrer kostengünstigen Architektur kann die Lösung nur auf OSI-Schicht 2 und darüber direkt messen. Auch wenn für Messungen auf der physikalischen Schicht (OSI-Schicht 1) in der Regel sehr teure Hardware benötigt wird, kann der WLAN-Monitor möglichst viele Erkenntnisse über die physikalische Schicht liefern. Der Monitor extrahiert alle verfügbaren Informationen über die physikalische Schicht und nutzt das Verhalten der oberen Schichten, um einige Eigenschaften der physikalischen Schicht abzuleiten.

In naher Zukunft wird es eine noch größere Vielzahl von teilweise kompatiblen Standards und eine enorme Menge an Daten geben, die auf die eine oder andere Weise QoS-Management unterliegen. Daher ist ein Fokus dieser drahtlosen Überwachungslösung die Erkennung und Identifizierung von Standardkonfigurationsparametern.

WLAN-Probleme aufspüren mit dem WLAN-Monitor: Architektur

Die Konstruktion der Architektur des WLAN-Monitors folgt durchgängig drei Hauptzielen:

1. Die Lösung soll auf unmodifizierter ”off-the-shelf”-Hardware lauffähig sein,
2. modular aufgebaut sein und
3. möglichst wenig Rechenleistung erfordern, um mobil ohne Netzstromversorgung für längere Zeit einsatzfähig zu sein.

Die Verarbeitungskette (siehe Abbildung 1) von Aufzeichnung des WLAN-Verkehrs bis zur Auswertung und Visualisierung ist dabei in Quasi-Echtzeit mit einer Verzögerung von nur wenigen Sekunden möglich. Dafür ist eine hohe Datenverarbeitungsgeschwindigkeit erforderlich, aber auch eine konsequente Anwendung des Prinzips der Datensparsamkeit: Jeder Verarbeitungsschritt erhält nur die Daten, die er auch benötigt. Und gleichzeitig reicht er nur diese weiter, die die folgenden Verarbeitungsschritte benötigen. Beispielsweise werden von der eigentlichen Monitoring-Logik alle Nutzdaten der Pakete verworfen und nur die Paketheader weiterverarbeitet, die für spätere Analysen tatsächlich notwendig sind.

Zusätzlich zur direkten Kette von WLAN-Interface zu Auswertung und Visualisierung ist es auch möglich pcap-Files (”packet capture”) aus beliebigen Quellen direkt einzulesen und völlig ident wie direkt aufgezeichneten WLAN-Verkehr weiterzuverarbeiten. Dies erweitert die Anwendungsbereiche des Tools, da dadurch auch Daten aus Drittquellen eingespielt werden können. Der WLAN-Monitor selbst speichert ebenfalls die Rohdaten direkt als pcap-File. Wenn dann bei der Auswertung und Visualisierung Probleme identifiziert werden, können diese, wo notwendig, in vollem Umfang direkt im aufgezeichneten WLAN-Verkehr mit zusätzlicher Industriestandardsoftware nachvollzogen werden.

WLAN-Probleme analysieren mit dem WLAN-Monitor: Modularer Aufbau

Der modulare Aufbau (siehe Abbildung 1) wird in den folgenden Unterkapiteln näher beschrieben:

Hardware

Die Nutzung unmodifizierter ”off-the-shelf”-Hardware eliminiert den Hardware-Entwicklungsaufwand, erfordert jedoch die sorgfältige Auswahl dieser. Die verwendete Hardware soll möglichst generisch sein, um die zukünftige Weiterentwicklung des WLAN-Monitors nicht an eine konkrete Hardware zu binden, gleichzeitig aber alle nötigen Feature unterstützen. Da sich der Monitor hardwareseitig auf die Aufzeichnung von WLAN-Verkehr ab OSI-Schicht 2 beschränkt, ist die Wahl der Rechnerplattform nur durch die Kompatibilität mit entsprechender WLAN-Hardware eingeschränkt. Um den Mobilitätsanforderungen gerecht zu werden, ist jedoch auf eine möglichst geringe Leistung zu achten.

Die realisierte Lösung baut auf einem Raspberry Pi 3. Anstatt der bei PCs dominierenden x86-Prozessorarchitektur basiert dieser auf der ARM-Architektur, die sich durch deutlich geringeren Energieverbrauch auszeichnet. Darüber hinaus kann ein Raspberry Pi einfach über die USB-Schnittstelle mit Elektrizität versorgt werden, was den mobilen Einsatz zusätzlich drastisch vereinfacht. Es ist so möglich, das Gerät vollständig nicht-invasiv an beliebigen Einsatzorten zu platzieren.

Grundsätzlich ist der Einsatz dieser WLAN-Monitoring-Plattform aber auf jeder Computerplattform mit Linux als Betriebssystem, dass die verwendeten in den folgenden Unterkapiteln näher beschriebenen Softwarekomponenten unterstützt, möglich.

Dem WLAN-Interface, als einzige Aufzeichnungsschnittstelle, kommt dabei eine Schlüsselrolle zu: Es muss möglichst den kompletten WLAN-Verkehr empfangen können. Es ist daher besonders auf hochqualitative Antennen und Empfänger zu achten. Firmewareseitig muss das Interface den sogenannten ”Monitor-Mode” unterstützen. Denn auch wenn der Empfänger grundsätzlich den kompletten WLAN-Verkehr verarbeitet, wird dieser üblicherweise gefiltert und nur der für das Gerät bestimmte Verkehr in die höheren Schichten weitergereicht. Der ”Monitor-Mode” umgeht diese Filterung und erlaubt somit höheren Schichten die Weiterverarbeitung des kompletten WLAN-Verkehrs inklusive Zusatzinformationen des Empfängers. In dieser Lösung wird ein USB-WLAN-Interface von ALFA Network eingesetzt. Diese haben sich im Bereich des Sniffings lang bewährt und zeichnen sich durch eine besonders gute Treiberunterstützung aus.

WLAN-Interface Steuerung – Airmon-NG

Airmon-NG ist Teil der Softwaresammlung Aircrack-NG und wird als freie Software unter GNU General Public-Lizenz (GPL) veröffentlicht. Diese Softwaresammlung stellt Tools für die Evaluierung der Sicherheit von WLAN-Netzen zur Verfügung und ist auf „Monitoring“, „Attacking“, „Testing“ und „Cracking“ spezialisiert.

Beim WLAN-Monitor wird Airmon-NG verwendet, um das Netzwerkinterface in den Monitor-Mode zu versetzen. Airmon-NG erstellt dazu ein weiteres (virtuelles) Netzwerkinterface, welches den kompletten WLAN-Traffic an die weiteren Verarbeitungsschritte weiterleitet.

Vorverarbeitung – Preprocessing

In dieser Stufe erfolgt sowohl die notwendige (automatisierte) Konfiguration des WLAN-Interfaces, als auch die Aufzeichnung der Rohdaten als pcap-File, sowie die Konfiguration der weiteren Verarbeitungsschritte. Die einzig notwendige manuelle Konfiguration ist die Festlegung auf das zu überwachende WLAN mittels Eingabe des jeweiligen WLAN-„Namens“ (Service Set Identifier, SSID). In der Vorverarbeitung werden dann alle WLAN-Kanäle auf Vorhandensein dieser SSID gescannt.

Ist dieser Kanal identifiziert, wird das Interface auf diesen eingestellt und mittels Airmon-NG in den Monitor Mode versetzt. In diesem Schritt wird der komplette Netzwerkverkehr zusätzlich mittels tcpdump in ein pcap-File für eventuelle spätere Analysen gespiegelt. Danach wird in diesem Schritt die weitere Verarbeitungskette der eigentlichen Monitor-Logik konfiguriert und initiiert.

Monitor-Logik

Die eigentliche Datenverarbeitung und Datenextrahierung erfolgt mittels Python-Programm welches den tatsächlichen Sniffing-Prozess initiiert und als Unix-Pipe den Datenstrom weiterverarbeitet. Als Schnittstelle zum Netzwerkinterface dienen dabei wahlweise Scapy oder TShark. Sowohl Scapy als auch TShark werden als freie Software unter GNU General Public-Lizenz (GPLv2+ bzw. GPL) veröffentlicht.

Scapy ist ein vollständiger Python-Packetsniffer, der für das eigentliche Sniffing auf die Library libpcap aufbaut und Wrapper zur Verfügung stellt. Dadurch ist Scapy vielfältig einsetzbar und bieten einen enormen Funktionsumfang. Gleichzeitig ist die Verarbeitungsgeschwindigkeit in Scapy jedoch relativ gering. Daher kann alternativ das wesentlich performantere Tshark eingesetzt werden.

TShark implementiert ebenfalls libpcap und stellt die Basis für den Quasi-Standard Sniffer Wireshark dar. Im Unterschied zu Scapy ist TShark ein eigenständiges ausführbares Programm. Die Anbindung an den Python-Monitor ist daher recht starr per Kommandozeilenargumente.

Ob Scapy oder TShark als Sniffer konfiguriert wird, unterscheidet sich je nach Schwerpunkt der jeweiligen Analysen.

Der Anwendungsbereich des Monitors ist jedoch auf die Analyse des Netzwerkes beschränkt, Datenpaketinhalte sollen nicht ausgewertet werden. Für die Analyse des Netzwerkes reicht die Auswertung einiger weniger Metadaten. Hier eine exemplarische Aufstellung aller ausgewerteten Felder und die dazugehörende Display-Filter-Notation in Klammer:

Aus jedem empfangenen Frame werde diese Felder extrahiert und weiterverarbeitet. Wenn TShark als Sniffer konfiguriert wurde, werden die Frames trotzdem in einem Scapy-kompatiblen Objekt gespeichert. Diese Äquivalenz beschränkt sich dabei auf die verwendeten Interfaces dieses Objekts, es soll kein vollständiges Scapy-Objekt rekonstruiert werden. Dies vereinheitlicht die Verarbeitung und vermeidet Inkonsistenzen zwischen den verschiedenen Konfigurationsoptionen. Gleichzeitig wird so die wesentlich höhere Performance von TShark im Vergleich zu Scapy größtmöglich erhalten.

Zu beachten ist, das nicht alle empfangenen Frames auch alle oben genannten Felder enthalten. Die SSID ist beispielsweise lediglich in Beacon oder Probe-Request Frames enthalten. Diese so erhaltene Zuordnung von MAC-Adresse zu SSID wird in einem Wörterbuch gespeichert. Um die weitere Verarbeitung zu vereinfachen werden die MAC-Addressen aller empfangener Frames mit den jeweiligen SSIDs aus dem Wörterbuch ergänzt. Danach werden diese Felder für jeden Frame in einer Datenbank gespeichert. Um die Performance weiter zu erhöhen, sammelt der Python-Monitor Frames von jeweils einer Sekunde und schreibt diese gesammelt in die Datenbank.

Datenbank – InfluxDB

Die im Monitoring-Prozess gewonnen Daten werden in der Zeitreihendatenbank InfluxDB gespeichert. InfluxDB wird als freie Software unter MIT-Lizenz veröffentlicht. Eine Zeitreihendatenbank unterscheidet sich von gewöhnlichen relationalen Datenbank hinsichtlich Optimierung auf Abfragen und Analyse unveränderlicher Daten.

Typischerweise werden einzelne Datenpunkte von Zeitreihen nur einmal in die Datenbank geschrieben und nicht mehr verändert. Abfragen beziehen sich hingegen meist auf große Datenmengen (große Zeiträume) bzw. Aggregationen davon. Eingangsseitig werden die Daten per Python-Influx-Client direkt über HTTP-Interface zu Influx übertragen. Die eigentlichen Datenbank-Insertions erledigt der Influx-Server autonom.

Wesentliche Framecharakteristika werden direkt in einer flachen Tabelle als binäre Werte gespeichert. Es werden beispielsweise nicht die Nummern der jeweiligen Frame-Typen gespeichert, sondern direkt, ob es sich um den zu beobachtenden Frame-Typ handelt oder nicht. Dies vereinfacht Abfragen späterer Verarbeitungsschritte und verschiebt die Auswertungslogik direkt in die Datenbank. Diese enthält folgende Felder (field keys) und Tags (tag keys) (für eine detaillierte Erläuterung der einzelnen Felder siehe oben):

Auswertung und Visualisierung – Grafana

Die Auswertung der Messungen und gespeicherten Daten erfolgt vollständig innerhalb der Analyse und Visualisierungsplattform Grafana. Grafana wird als freie Software unter Apache 2.0-Lizenz veröffentlicht. Grafana integriert einen eigenen Webserver und stellt für den Anwender eine Weboberfläche, in der die vollständige Bedienung erfolgt, zur Verfügung. Grafana ist logisch in einzelne Dashboards aufgeteilt, die in der Weboberfläche jeweils als eigene Unterseiten dargestellt werden.

Der WLAN-Monitor hat unterschiedlichste Dashboards umgesetzt, die den Anwender einen übersichtlichen Blick auf die Netzwerksituation erlauben und bei der Identifizierung und Analyse konkreter Probleme unterstützen sollen. Die Dashboards haben daher unterschiedliche Abstrahierungs- und Detailstufen; von komplett textuell, bis vollständig als Diagramme ausgeführt, je nach Schwerpunkt des jeweiligen Dashboards:

In jedem Dashboard kann die Ansicht auf beliebige Zeiträume eingeschränkt werden. So kann beispielsweise ein grober Überblick über die Auslastung, Anzahl der Clients, etc. in einem großen Zeitraum erhalten werden, oder aber bis auf einzelne Frames vergrößert werden. Es werden allgemeine Dashboards zur Verfügung gestellt, die eine Übersicht über die Netzwerksituation geben und die einzelnen Clients und WLAN-Netze und Informationen dazu auflisten. Für konkrete Problemanalysen gibt es spezifische Dashboards, beispielsweise Dashboards konkret für die Analyse von Authentifizierungsproblemen oder etwa Netzüberlastungen.

Diese grafische Aufbereitung soll dabei helfen, die Information auf das wesentliche übersichtlich zu reduzieren und so einem Experten die Problemidentifizierung erst zu ermöglichen. Große Datenmengen können so dargestellt werden, der Blick auf das ”Große Ganze” erst ermöglicht.

Mehr Information zu den Forschungsarbeiten: 5G-MLab & 5G-AI-MLab