WLAN bis zum Endgerät, oder doch besser Ethernet?

Kennen Sie dieses lustige kleine Symbol bei Windows unten rechts in der Taskleiste? Sieht irgendwie aus wie ein Bildschirm, an dem links oben eine Maus klebt. Abbildung 1 zeigt dieses Symbol vergrößert auf der rechten Seite. Wahrscheinlich soll es einen überdimensionalen RJ45-Stecker darstellen. Es bedeutet, dass der Computer über Ethernet kommuniziert. Das linke Symbol dagegen zeigt eine Verbindung über WLAN an, ziemlich unmissverständlich, wie wir finden. Natürlich gibt es auch noch ein entsprechendes Symbol für die Mobilfunkverbindung, auch unmissverständlich. Das soll jedoch hier nicht weiter betrachtet werden.

Auch wenn Ihr Computer über beide Medien verbunden ist, wird immer nur eines dieser Symbole angezeigt. Woher wissen Sie also, ob beide Verbindungen bestehen? Schauen Sie in den Einstellungen unter „Netzwerk und Internet“ nach (Abbildung 2). Hier sehen Sie, dass der Rechner gerade über Ethernet und WLAN verfügt.

Stattdessen können Sie auch die Routen aus dem Betriebssystem abfragen. Mittels eines PowerShell-Befehls lässt sich die etwas längliche Ausgabe filtern, wie in Abbildung 3 dargestellt. Im Beispiel erkennen Sie tatsächlich zwei Einträge für Default Gateways. Sie weisen auf denselben Router (10.1.2.1), und die Interface-Adressen stammen aus demselben Subnetz. Bei vielen unserer Kunden stammten die Adressen jedoch aus unterschiedlichen Subnetzen.

Unterschiede gibt es in der letzten Spalte, der sogenannten Metrik. Kleinere Metrik bedeutet höhere Routen-Präferenz. In diesem Fall wird der Computer seine Pakete über die Schnittstelle mit der Adresse 10.1.2.101 versenden. Das ist die Ethernet-Schnittstelle.

Wie wird nun die Metrik bestimmt? Microsoft veröffentlicht hierzu einen Artikel in [1]. Demnach ergibt sich die Metrik aus der Bitrate des jeweiligen Adapters. In Tabelle 1 finden Sie die Werte für Bitraten zwischen 4 Mbit/s und 2 Gbit/s. Tatsächlich sind darunter und darüber noch weitere Werte definiert, die Sie in [1] nachschlagen können.
Nehmen wir als Beispiel das Büro bei ComConsult. Dort ist ein Ethernet-Endgerät normalerweise mit 100 Mbit/s angebunden, also Fast Ethernet. Nur Power-User, z.B. die Kollegen unserer CAD-Abteilung, erhalten einen Anschluss mit Gigabit-Ethernet. Das führt dazu, dass viele unserer Kollegen grundsätzlich über WLAN arbeiten, denn dort wird flächendeckend IEEE 802.11ac angeboten. Ungeachtet der Tatsache, dass sich im WLAN meist mehrere Kollegen denselben Kanal auf der Luftschnittstelle teilen, erkennt Windows eine Bitrate größer 100 Mbit/s. Es würde also gar nichts nützen, wenn die Kollegen ihren Laptop ans Ethernet anschlössen, denn WLAN hätte nach wie vor die bessere Metrik (z.B. 30 gegenüber 35).

Uns hat interessiert, ob für die Ermittlung der Metrik die theoretisch mögliche oder die tatsächliche Bitrate maßgeblich ist. Wir haben dazu folgendes Testszenario aufgebaut (vgl. Abbildung 4):

• Der Laptop steht auf einem Schreibtisch im Arbeitszimmer. Er ist über Fast Ethernet mit einem Layer-2-Switch verbunden.
• Im Nachbarzimmer befindet sich ein WLAN Access Point. Der Laptop ist an dem vom AP abgestrahlten WLAN assoziiert.
• Die Tür zwischen den Räumen lässt sich schließen. Dadurch sinkt die Signalstärke am WLAN-Adapter des Laptops so weit ab, dass dieser auf ein Modulation and Coding Scheme (MCS) mit geringerer Bitrate umschaltet.

Zunächst haben wir mittels der Windows „NetShell“ die Parameter der aktuellen WLAN-Verbindung abgerufen. Abbildung 5 zeigt, dass der Laptop mit MCS 9 bei 80 MHz Kanalbandbreite und 2 Spatial Streams angebunden ist, also 866 Mbit/s brutto. Laut Tabelle 1 ergibt sich somit eine Metrik von 30. Auf der anderen Seite ist der Laptop mit Fast Ethernet im Netz, was eine Metrik von 35 ergibt.

Wir wollten nun wissen, was passiert, wenn die Tür geschlossen wird. In diesem Fall ergab die Abfrage gemäß Abbildung 5 eine Bitrate von 180 Mbit/s, d.h. MCS 4 bei 40 MHz Kanalbandbreite und 2 Spatial Streams. Laut Tabelle 1 müsste also die Metrik nun auf 45 angestiegen sein. Das konnten wir tatsächlich beobachten.

Erste Erkenntnis: Die von Windows verwendete Routing-Metrik hängt bei WLAN-Adaptern von der tatsächlich genutzten Bitrate ab.

Die spannende Frage ist, wie sich eine solche Veränderung der Metrik auf bestehende Datenverbindungen auswirkt. Wir haben das Testszenario um verschiedene Verbindungen ergänzt. Besonders gut gelang uns der Nachweis unter Nutzung einer Sprach- und Video-Verbindung über Microsoft Teams in Kombination mit ICMP Echo Requests („Ping“). Hierzu haben wir Paketaufzeichnungen gemacht, und zwar gleichzeitig auf dem WLAN-Adapter und auf dem Ethernet.

Die statistische Auswertung erkennen Sie in Abbildung 6:

• Die grüne Linie symbolisiert die infolge des Ping ausgetauschten Pakete.
• Die roten Nadeln zeigen die Pakete der Medienströme von Teams an.
• Nach Sekunde 65 wurde die Tür geschlossen.
• Nach Sekunde 100 wurde sie wieder geöffnet.

Man sieht, dass zunächst erwartungsgemäß alle Daten über die WLAN-Verbindung geroutet werden. Sinkt die Bitrate ab, ändert sich die Metrik des WLAN-Adapters, und die „Pings“ werden nun in Richtung Ethernet geroutet. Die Medienströme laufen jedoch unverändert über das WLAN. Und genauso war es auch mit TCP-Verbindungen, wie wir in verschiedenen nachfolgenden Tests feststellen konnten. UDP-Medienströme und TCP-Verbindungen „kleben“ an ihrem Adapter.

Warum ist das so? Nun, TCP- und UDP-Pakete werden sogenannten Flows zugeordnet. Mit anderen Worten, alle Pakete eines UDP-basierenden Medienstroms gehören zu einem Flow. Alle Pakete einer TCP-Verbindung von Station A nach B gehören zu einem Flow, alle Pakete in Gegenrichtung von B nach A zu einem zweiten. Genau genommen wird ein Flow durch ein „5-Tupel“ beschrieben, also durch 5 Werte, die den Flow eindeutig identifizieren:

1. IP-Quelladresse
2. IP-Zieladresse
3. Protokoll (TCP bzw. UDP)
4. TCP- bzw. UDP-Quellport
5. TCP- bzw. UDP-Zielport

Der Flow ist also insbesondere fest mit IP-Ziel- und Quelladresse verknüpft. Es ist somit gar nicht möglich, den Flow über einen anderen Adapter zu leiten, wenn sich die Metrik ändert. Aussenden des Pakets über einen anderen Adapter impliziert, dass die IP-Quelladresse einen anderen Wert, nämlich den des anderen Adapters annimmt. Im Gegensatz dazu ist ICMP Echo nicht an einen Flow gebunden.

Zweite Erkenntnis: Ein Flow ist immer an einen Adapter gebunden.
Ungeachtet dessen können im geschilderten Setup verschiedene Flows über verschiedene Adapter laufen. Es hängt letztlich davon ab, welche Routing-Metrik bestand, als der Flow begann. Stellen Sie sich hierzu nun bitte folgendes Beispiel vor:

• Der Laptop verfügt über ein Softphone und baut damit eine Telefonverbindung mittels Session Initiation Protokoll (SIP) auf. Zu diesem Zeitpunkt hat der Ethernet-Adapter die bessere Metrik. Der entsprechende Flow wird somit an das Ethernet gebunden.
• Just in diesem Moment tritt jemand zur Tür herein. Die WLAN-Verbindung wird infolgedessen schlagartig besser.
• Der angerufene Teilnehmer hebt ab und die Medienströme, welche die Sprache transportieren, werden initiiert. Typischerweise handelt es sich dabei um das Real-Time Transport Protocol (RTP). Die RTP Flows werden nunmehr an den WLAN-Adapter gebunden, weil dieser jetzt die bessere Metrik aufweist.

Grundsätzlich ist das kein Problem. Der Verbindungsaufbau wird im Ethernet initiiert, die Medienströme laufen über WLAN. Allerdings haben viele unserer Kunden ihr WLAN gegenüber dem LAN oder dem RZ mit einer Firewall abgesichert. Damit die Firewall die Medienströme durchlässt, muss sie wissen, welche UDP-Ports auf Sender- und Empfängerseite genutzt werden. Diese Information steckt im SIP, genau genommen im darin enthaltenen Session Description Protocol (SDP). Das SDP kommt im gewählten Beispiel aber gar nicht an der Firewall vorbei. Der entsprechende Flow wurde ja über das Ethernet geleitet.

Abbildung 7 skizziert die resultierenden Flows. Grün ist der Weg des SDP über das LAN, rot der Weg des RTP über WLAN und Firewall, die letztlich eine Verbindung verhindert.

Fazit: Dem Anwender wird signalisiert, dass sein Gegenüber abgehoben hat. Sein Gegenüber wird jedoch nichts hören. Es kann sogar sein, dass er seinen Gesprächspartner hört, je nachdem, welche Routing-Präferenz dort vorherrscht. In der Abbildung 7 ist das sogar wahrscheinlich, weil der andere Teilnehmer (IP Phone) gar keinen WLAN-Adapter besitzt, das Routing also eindeutig ist.

Die Metrik verstellen?

Was kann man tun? Eine Möglichkeit besteht darin, die Metrik anzupassen. Man öffne die Einstellungen des IPv4-Protokolls im Ethernet-Adapter (Abbildung 8) und setze die „Schittstellenmetrik“ manuell auf einen kleinen Wert, z.B. auf eins. Vergessen Sie dabei nicht, dies auch für IPv6 zu tun, wenn das bei Ihnen zum Einsatz kommt.

Genauso gut können Sie die Einstellung mittels PowerShell vornehmen. Hierzu müssen Sie lediglich die Nummer des Adapters („InterfaceIndex“) kennen. In Abbildung 9 sehen Sie, dass zunächst die Metrik für beide Protokolle auf „Automatik“ steht (kein Eintrag in der Spalte „InterfaceMetric“). Nach Ausführen des Befehls ist die Metrik für beide Protokolle gesetzt.

WLAN-Adapter automatisch deaktivieren?

Eine andere Variante könnte im automatischen Deaktivieren des WLAN-Adapters liegen, sobald der Laptop mit dem Ethernet verbunden ist. Hierfür bieten Hardware- und Software-Hersteller zahlreiche Möglichkeiten an, die wir im Folgenden betrachten werden. Bevor man sich im Unternehmen für eine dieser Lösungen entscheidet, sind jedoch einige Anforderungen bzw. Auswahlkriterien an eine solche Lösung zu beachten:

• • Hardware-Unabhängigkeit: Aus betrieblichen Aspekten kann es notwendig werden, dass alle infrage kommenden Mechanismen zur automatischen Abschaltung des WLAN-Adapters unabhängig von der eingesetzten Hardware funktionieren. Gerade in großen Unternehmen ist es niemals möglich und gegebenenfalls auch nicht gewünscht, ein einziges Laptop-Modell allen Mitarbeitern zur Verfügung zu stellen. Sobald jedoch Mechanismen zur automatischen Abschaltung des WLAN-Adapters nur bei einer Teilermenge der Geräte funktionieren, ist diese Lösung für den Einsatz in großen Unternehmen untauglich.

• Anwenderfreundlichkeit: Vor kurzem erzählte uns ein Kunde von einem Anwender, der zwar den Umgang mit modernen Kommunikationsmitteln ordentlich beherrscht und konsequent nutzt, aber sofort scheitert, sobald die Technik nicht so funktioniert, wie sie soll. Es stellte sich in dem besagten Fall schnell heraus, dass das Internet nicht ausgefallen und der Anruf beim IT-Support unnötig war. Stattdessen hätte es einfach nur ein paar Mausklicks bedurft, um den WLAN-Adapter wieder zum Leben zu erwecken. Was ist damit gemeint: Automatisch heißt automatisch! Es darf also in keinem Fall passieren, dass der Endanwender irgendeinen Knopf drücken oder irgendeine Software starten muss, um störungsfrei kommunizieren zu können. All dies führt nur zu Frust und Ärger beim Anwender sowie zu vermeidbarer Arbeit bei der Support-Hotline.
• Rollout und Betrieb: Die anzuwendende Lösung muss möglichst einfach in die Installationsprozesse (Staging) der Endgeräte integriert werden können. Auch bezüglich der Erstinstallation sind insbesondere Mechanismen zu bevorzugen, die tunlichst ohne oder zumindest mit einem minimalen manuellen Aufwand implementiert werden können. Alle Mechanismen, die in die automatisierte Softwareverteilung, in Konfigurationsskripte oder – wie bei Windows üblich – in eine Gruppenrichtlinie integriert werden können, sind hier klar im Vorteil.
• Beachtung von Spezialfällen: Kann es notwendig sein, dass der WLAN-Adapter aktiv bleiben muss, auch wenn das Endgerät mit dem Ethernet verbunden ist? Ja! Beispielsweise kann der WLAN-Adapter des Laptops zur Projektion des Bildschirminhaltes auf ein TV-Gerät oder einen Projektor verwendet werden. Hierfür nutzt der WLAN-Adapter unter Windows oftmals Miracast, einen von der Wi-Fi-Allianz zertifizierten Funkstandard, wobei in der Regel über ein Peer-to-Peer-WLAN eine Verbindung zum Projektor aufgebaut wird, die parallel zur möglicherweise aktiven Verbindung in ein Infrastruktur-WLAN genutzt werden kann. Steckt man nun ein Ethernetkabel in den Laptop, passiert, was passieren muss: Die Bildübertragung wird beendet, da der WLAN-Adapter vom Betriebssystem deaktiviert wird. Ein anderer Anwendungsfall könnte beispielsweise sein, dass zu einem Laptop eine Remote-Verbindung über Ethernet aufgebaut wird und gleichzeitig die WLAN-Schnittstelle zu Monitoring-Zwecken aktiviert sein muss. Solche Konstrukte nutzen wir selbst gerne im Rahmen von Fehlersuche- und Messaufgaben. Zugegeben, Nutzer die solche Dinge tun, kommen auch mit anwenderunfreundlichen Situationen zurecht.

Gängige Mechanismen und Werkzeuge zur Deaktivierung des WLAN-Adapters

Die Liste der Mechanismen, die für eine automatische Deaktivierung des WLAN-Adapters genutzt werden können, ist lang. Manche davon sind durchaus tauglich, andere wiederum nicht. Es ist schließlich wie bei vielen anderen Dingen auch, nicht jede Lösung passt zu jedem Szenario:

• Nutzung des BIOS / UEFI: Im BIOS bzw. UEFI [4] gängiger Laptops lässt sich das Verhalten des WLAN-Adapters einstellen. So findet man beispielsweise im Power Management des BIOS ein Untermenü „Wireless Radio Control“. Dahinter verbirgt sich die gesuchte automatische Deaktivierungsfunktion und zwar interessanterweise für den WLAN-Adapter und den Mobilfunkadapter. Diese Einstellung haben wir erfolgreich an unseren Geräten im Rahmen der Recherche für diesen Artikel getestet. Es ist jedoch Vorsicht geboten; nicht jedes Laptop-Modell bietet diese Funktion an. Zudem kann es vorkommen, dass diese Funktion nur mit ausgewählten WLAN-Adaptern verfügbar ist oder – schlimmer – von speziellen Treiberversionen abhängt. Es empfiehlt sich also, auf die gewünschten Funktionen bereits während des Beschaffungsprozesses zu achten und diese entsprechend ins Pflichtenheft aufzunehmen.
• Dienstprogramme der Adapter-Hersteller: Die Hersteller der WLAN-Adapter liefern in vielen Fällen zusätzlich zu den Gerätetreibern Dienstprogramme, mit deren Hilfe sich zahlreiche erweiterte Einstellungen, wie auch die automatische Deaktivierung des WLAN-Adapters, durchführen lassen. Ein Beispiel hierfür ist die Software „PROSet Wireless“ des Herstellers Intel. Wie zu erwarten, ist die gewünschte Funktion gegeben, die Verfügbarkeit dieser Tools jedoch wiederum von Hardware und Treiber abhängig. Analog verhält es sich übrigens bei den erweiterten Treibereinstellungen der WLAN-Adapter. Auch ohne Installation dieser erweiterten Dienstprogramme, die viele Nutzer als „Bloatware“ abtun und daher erst gar nicht installieren, lässt sich hier in den erweiterten Einstellungen des WLAN-Adapters die gewünschte Einstellung vornehmen. Die Bezeichnung des gesuchten Konfigurationsparameters variiert dabei. Bei Broadcom nennt er sich „Disable upon Wired Connect“.

• • Skripte und Shareware-Tools: Im Internet finden sich zahlreiche Shareware-Tools oder auch Visual-Basic- und Powershell-Skripts (z.B. in [2]), die ebenfalls den WLAN-Adapter deaktivieren und auch wieder aktivieren können. Diese Skripte nutzen die vom Betriebssystem erzeugten Systemereignisse (Logging-Meldungen) als Trigger, wie zum Beispiel die Event-ID: “3 – Network link has been established” oder “27 – Network link is disconnected”. Nutzer solcher Skripts berichten jedoch auch, dass diese schon einmal aus dem Tritt kommen, wenn z.B. aus irgendeinem Grund der Trigger, also die Meldung eines System-Events ausbleibt. Insgesamt sind solche Skripts daher mit Vorsicht zu genießen und eher etwas für den geneigten Privatanwender.
  • Gruppenrichtlinien: Gruppenrichtlinien (GPO) eigenen sich prinzipiell gut, da sie innerhalb eines Domänen-Netzwerks automatisiert ausgerollt werden können. Es muss natürlich die zum Problem passende GPO dabei sein. Ein Beispiel hierfür ist die GPO „Verbindung mit Nicht-Domänennetzwerken bei vorhandener Verbindung mit domänenauthentifiziertem Netzwerk nicht zulassen“. Diese findet sich in den „Richtlinien für Lokale Computer“ im Untermenü „Administrative Vorlagen“ – „Netzwerk“ – „Windows-Verbindungs-Manager“. Das Aktivieren dieser GPO ist natürlich nur die halbe Miete, da schließlich auch die zweite Netzwerkverbindung, etwa die WLAN-Verbindung, mit einem domänenauthentifizierten Netzwerk verbunden sein kann. Zudem wird über mögliche Probleme berichtet, falls auf dem Computer weitere Netzwerk-Interfaces wie zum Beispiel Loopback-Interfaces oder Interfaces von Virtualisierungsprogrammen vorhanden sind.

• Eine weitere Gruppenrichtlinie im selben Untermenü heißt „Anzahl gleichzeitiger Verbindungen mit dem Internet oder einer Windows-Domäne minimieren“. Wenn Sie diese GPO aktivieren und den Wert 3 eintragen, kann ein Anwender seinen Laptop nicht mit dem WLAN verbinden, sobald eine Ethernet-Verbindung aktiv ist. Beim Verbindungsversuch erscheint eine Fehlermeldung gemäß Abbildung 9. Die Bedeutung der übrigen Optionen ist im Gruppenrichtlinien-Editor detailliert beschrieben.
• VPN-Clients: Gerade für mobile Nutzer werden VPN-Verbindungen auf den Endgeräten eingerichtet, die es den Nutzern erlauben, über einen abgesicherten Weg aus öffentlichen Netzen ins Firmennetzwerk zu kommunizieren. Als Alternative zum Windows-eigenen VPN-Client kommen hierfür auch herstellerspezifische, also zum jeweiligen VPN-Gateway passende, VPN-Clients zum Einsatz. Beispiele für solche Produkte sind etwa Pulse Connect Secure, Cisco AnyConnect oder OpenVPN. Derlei Clients sind ebenfalls in der Lage, eine zweite Netzwerkverbindung zu unterbinden, wie Microsoft in seinem Artikel unter [3] bemerkt. Bei einigen dieser VPN-Lösungen erkennt das Betriebssystem deren (virtuelle) Adapter als Ethernet-Adapter. In diesem Fall sägt sich Windows den Ast ab, auf dem es sitzt, sobald Sie mit einem WLAN verbunden sind und dann Ihre VPN-Verbindung aktivieren. Immerhin konnten wir nachweisen, dass sich das Microsoft-eigene VPN in dieser Hinsicht vorbildlich verhält.

Diese, bestimmt nicht vollständige, Liste der Möglichkeiten zeigt, dass sicherlich für jeden Anwendungsfall und für jede Umgebung ein passendes Tool bzw. ein passendes Verfahren zu finden ist. Wichtig ist, dass bei dessen Auswahl auf die Erfüllung der zuvor genannten Kriterien geachtet wird. Dies ist jedoch immer individuell zu betrachten.

Kabel ab!

Bei uns und auch bei vielen unserer Kunden sind bereits seit Längerem flächendeckende WLANs in Betrieb. Schlagwörter wie „All Wireless Office“ oder „Wi-Fi First“ sind zudem in aller Munde. Bedingt durch die Art und Weise, wie wir arbeiten und vor allem wo wir arbeiten, sind wir es in der Tat gar nicht mehr gewohnt, einen kabelgebundenen Netzwerk-Anschluss zu nutzen. Dieser Effekt wird durch die aktuelle Lage, die dazu führt, dass viele von zu Hause aus arbeiten, noch verstärkt.

Also warum verzichten wir alle nicht öfter auf das Kabel und machen damit die zuvor aufgezählten Probleme obsolet? Natürlich müssen dafür leistungsfähige und flächendeckende WLANs vorhanden sein, jedoch sind diese Voraussetzungen oftmals schon längst erfüllt. Gerade als Planer von WLAN-Infrastrukturen und als Berater bzw. Trainer zu sämtlichen Themen rund um kabellose Netze praktizieren wir dies, gewissermaßen im Selbstversuch, bereits seit Jahren erfolgreich.

Links und Verweise

[1] https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/automatic-metric-for-ipv4-routes, abgerufen am 21.02.2021

[2] https://zamarax.com/2019/07/31/how-to-automatically-turn-off-wi-fi-when-an-ethernet-cable-is-connected/, abgerufen am 21.02.2021

[3] https://docs.microsoft.com/de-de/troubleshoot/windows-client/networking/windows-connection-manager-disconnects-wlan, abgerufen am 21.02.2021

[4] Unified Extensible Firmware Interface