Seit dem Update auf Android 11 / OxygenOS 11 habe ich einen Bug beim WLAN-Roaming auf meinem Oneplus 6. Ich kann den Fehler mittlerweile nachstellen (das Roaming schlägt immer dann fehl, wenn während des Roamings der Screen gesperrt ist), dennoch werde ich um eine Paketanalyse nicht herumkommen, wenn ich Details verstehen möchte. So kann ich das Problem weiter eingrenzen oder auch die Capture-Datei direkt an den Oneplus-Support schicken. Das Problem beim Capturing von WLAN-Roaming? Es müssen mehrere Kanäle gleichzeitig gesnifft werden. Wie das geht, zeige ich euch jetzt!
Zum Packet Capturing in Roaming-Szenarien müssen mehrere Kanäle gleichzeitig mitgeschnitten werden. Dazu braucht man genauso viele WLAN-Adapter wie Kanäle, die man sniffen möchte. In meinem Testsystem sind das zwei Kanäle, dazu brauche ich also zwei Adapter. Jeden Adapter stelle ich auf einen entsprechenden Kanal (zum Beispiel 6 und 11) ein und starte das Monitoring. In Wireshark fasse ich dann die Ergebnisse zu einer Ansicht zusammen. Es ist nicht zielführend, nur einen Adapter für beide Kanäle zu verwenden, da ansonsten wichtige Pakete während des Scannens verloren gehen, die auf dem einen Kanal übertragen werden, während der Adapter gerade den anderen Kanal abhört.
Roaming geht immer über mehrere Kanäle
Mehrere Access Points werden immer dann eingesetzt, wenn die Kapazität und die Abdeckung des WLANs erhöht werden soll. WLAN-Roaming bezeichnet das Wechseln zwischen solchen Access Points innerhalb einer gleichen SSID (WLAN-Name) und wird immer vom Endgerät durchgeführt. Die Infrastruktur kann hierbei Unterstützung anbieten und notfalls das Endgerät über Umwege zu einer Art Wechsel des AP zwingen. Ob das dann noch Roaming ist oder vielmehr ein technischer Rausschmiss eines Endgerätes, darüber streiten sich die Gelehrten.
Wie dem auch sei, wenn mehrere Access Points WLAN mit gleicher SSID bereitstellen (Stichwort Mobility Domain), können Sie nicht auf der gleichen Frequenz funken. Das würde das WLAN stark verlangsamen, da das genutzte Frequenzspektrum eine begrenzte Kapazität hat. Würden sich beide Access Points diese Frequenz teilen müssten, würde sich der Durchsatz des WLANs halbieren (Co-Channel-Interference). Und genau das möchte man nicht, wenn man die Kapazität des WLANs doch eigentlich erhöhen möchte.
Beim WLAN-Roaming wechselt das Endgerät also die Frequenz: Vom Kanal des ersten Access Points auf die Frequenz eines zweiten Access Points der gleichen SSID.
Genutzte Kanäle müssen beobachtet werden. Vollständig.
Möchte man WLAN-Roaming gewissenhaft untersuchen, müssen die entsprechenden Funkpakete analysiert werden. Und zwar auf beiden Kanälen, d.h. sowohl auf der Frequenz des ersten Access Points (und auf dem sich auch der Client noch befindet) und auf der Frequenz des neuen Access Points.
Wie man den Funkverkehr mitschneidet, habe ich bereits ausführlich erklärt, zum Beispiel unter Kali Linux mit dem AWUS036ACH oder mit Aruba Instant. Beide Methoden kommen heute zum Einsatz und werden entsprechend ausgebaut, um Packet Capturing auf zwei Kanälen durchzuführen. Lest euch die Artikel am besten zur Vorbereitung durch.
Neu in diesem Zusammenhang und wichtig: Pro Kanal, der abgehört werden soll, wird ein separater Funkchip benötigt. Theoretisch kann ein WLAN-Adapter zwar mehrere Kanäle abhören, jedoch kann er immer nur einen Kanal gleichzeitig erfassen. Das liegt an den physikalischen Gegebenheiten der Funkfrequenzen. Der WLAN-Adapter würde dann zwischen beiden Kanälen, welche ich untersuchen möchte, immer hin und her wechseln. Die halbe Zeit würde er beispielsweise auf Kanal 6 lauschen, die andere Hälfte der Zeit würde er auf Kanal 11 hören. Wenn aber zwischen Access Point und Endgerät auf Kanal 6 gefunkt wird, während der WLAN-Adapter im Monitor Mode auf Kanal 11 lauscht, würde das Paket nicht erfasst. Das ist nicht nur ärgerlich, sondern kann zu völlig falschen Rückschlüssen bei der Problemanalyse führen. Für ernsthaftes Debugging brauchen wir eine vollständige Erfassung aller Funkpakete.
Möglichkeit 1: Roaming-Analyse mit zwei WLAN-Adaptern unter Kali Linux (Monitor Mode)
Für Möglichkeit 1 benötigen wir zwei WLAN-Adapter, welche den Monitor Mode unterstützen. Ich arbeite heute mit dem bereits bekannten AWUS036ACH und dem AWUS1900, beide Geräte von Alfa Networks. Ich habe Sie für verschiedene Szenarien häufig im Einsatz. Besonders charmant: Beide WLAN-Adapter lassen sich bequem per USB anschließen und laufen unter Kali mit dem gleichen Treiber. Die Treiberinstallation habe ich euch bereits hier gezeigt.
Schließt also beide Adapter an Kali an und dann geht es auch schon los. Airmon-ng wird gestartet, um zu überprüfen, ob beide Adapter von Kali erkannt wurden und ob die Treiber ordnungsgemäß installiert wurden.
sudo airmon-ng
Anschließend wie gewohnt die störenden Prozesse beenden, damit das Monitoring später nicht abstürzt. Dies geschieht mit folgender Eingabe.
sudo airmon-ng check kill
Gebt den Befehl ruhig zweimal ein, beim zweiten Mal erkennt ihr, ob alle Prozesse auch wirklich beendet wurden. Dann werden die beide WLAN-Adapter nacheinander in den Monitor Mode versetzt. Für folgenden Befehl müsst ihr den Namen der WLAN-Adapter verwenden, wie sie euch oben nach „sudo airmon-ng“ angezeigt wurden.
sudo airmon-ng start wlan0 6
sudo airmon-ng start wlan1 11
Im Anschluss befinden sich beide WLAN-Adapter im Monitor Mode. Nun wird Wireshark gestartet, um die Pakete mitzuschneiden.
In Wireshark können die Ergebnisse beider Adapter in einer Ansicht zusammengefasst werden. Im Startbildschirm von Wireshark wählt ihr dazu bitte beide Adapter gleichzeitig aus. Um beide Adapter auszuwählen, haltet die STRG-Taste gedrückt und klickt auf die gewünschten Adapter. Nachdem beide Adapter ausgewählt wurden, kann das Aufzeichnen von Paketen über das bekannte Wireshark-Icon gestartet werden (oben links).
Wireshark zeigt nun alle Pakete von beiden Paketen vollständig an. Die Spalte WLAN-Kanal beweist, dass nur Pakete von Kanal 6 und Kanal 11 gecaptured werden. Also genau so, wie wir die Adapter mit airmon-ng eingestellt haben.
Von nun an geht es weiter mit Wireshark wie gewohnt, zum Beispiel mit der Entschlüsselung der Data Frames im eigenen WLAN, welche zusätzlichen Einblick in die Vorgänge gibt. Übrigens: Das Wireshark-Profil, welches ich verwendet habe, stelle ich euch in Kürze zur Verfügung.
Möglichkeit 2: Roaming-Analyse direkt an den Access Points Aruba Instant (Packet Capturing)
Wer kann, nutzt für die zweite Möglichkeit seine bestehende Infrastruktur zum Packet Capturing. In meinem Beispiel sind das zwei Aruba Instant Access Points. Die Idee ist: Während die APs mein Oneplus 6 versorgen, befinden Sie sich automatisch immer auf den richtigen Kanälen. Im Beispiel stellen Sie auf den Kanälen 6 und 11 WLAN bereit. Das nutzen wir aus und machen einfach einen Paketmitschnitt mit allen relevanten Infos.
Vorteil: Wenn während der Übertragung zwischen Smartphone und Access Point irgendwelche Fehler durch Funkstörungen auftreten, regeln beide Geräte als Teil des WLAN-Standards die erneute Übertragung der Daten und keine Information geht verloren. Auch diese Störung ist teil der Paketanalyse und wichtig für die Auswertung. Oben beschriebene Möglichkeit 1 tut sich in diesem Kontext sehr schwer: Wenn die Übertragung zwischen AP und Endgerät störungsfrei abläuft, bedeutet dies nicht automatisch, dass die Übertragung zum WLAN-Adapter mit Monitor Mode ordnungsgemäß funktioniert. Es könnte beim Empfang am WLAN-Adapter zu einer Funkstörung bekommen sein. Diese Störung wird zwar aufgezeichnet, Access Point und Endgerät machen aber weiter, da für Sie keine Störung vorliegt. Die Interpretation der Paketanalyse könnte dadurch aber verfälscht werden.
Die meisten professionellen und semi-professionellen Access Points sollten Packet Capturing anbieten können. Wenn nicht: Entweder besseres Equipment kaufen oder auf Möglichkeit 1 ausweichen! Klappt aber zum Beispiel aber auch mit OpenWRT oder UniFi, sofern ihr euch mit tcpdump etwas auskennt. Ich selbst bin kein tcpdump-Profi, aber diese Anleitung hat mir schon oft aus der Patsche geholfen.
Geht also vor wie in meiner Anleitung zum Packet Capturing mit Aruba Instant. Wiederholt den Vorgang je Access Point, den ihr in die Analyse einbeziehen wollt. Für Kanal 6 und 11 je einmal, also insgesamt zweimal.
Im Schnelldurchlauf: Putty starten, SSH-Verbindung zum ersten AP aufbauen und einloggen, Interface mit „show ap monitor status“ identifizieren, Capturing mit „pcap start xx:xx:xx:xx:xx:xx 192.168.230.26 5555 1 10000“ starten. Dann den Vorgang mit dem zweiten Access Point wiederholen.
Anschließend Wireshark starten. Im Startbildschirm wählt den Netzwerkadapter eures Computers aus, über welchen die Verbindung zu den Access Points aufgebaut wurde. Nutzt folgenden Capture Filter „udp port 5555“ (damit nur der Capture-Stream geloggt wird und nicht der normale Datenverkehr des PCs) und startet dann die Aufzeichnung der Pakete in Wireshark. Vergesst nicht, die Pakete der Access Points zu Dekodieren, damit ihr die UDP-Pakete lesen könnt.
Lasst euch nicht verunsichern, wenn Putty nach einiger Zeit die Verbindung schließt. Das Packet Capturing läuft auch ohne Putty weiter. Vergesst aber nicht, nach Abschluss der Arbeiten das Capturing pro Access Point unbedingt wieder mit „show pcap status“ bzw. „pcap stop xx:xx:xx:xx:xx:xx 1“ zu beenden (auf die ID achten!).
Wireshark zeigt euch alle Pakete an, die von beiden Access Points per UDP an den Computer verschickt werden. In unserem Beispiel schickt ein Access Point Alles von Kanal 6, der zweite AP alle Pakete von Kanal 11. Super Sache und eben zuverlässiger als Möglichkeit 1.
Nun kann ich mich endlich der Analyse dieses ominösen Bugs auf meinem OnePlus 6 widmen. Die notwendigen Pakete habe ich nun vollständig erfasst! Wünscht mir viel Erfolg, denn Lust darauf habe ich nicht…