Probleme beim Wechsel Ethernet - WIFI
Hallo, nach langer Zeit gibt es mal wieder einen Gastbeitrag aus dem Windows Netzwerk Support von Frank Hennemann.
Vor kurzem habe ich an einer interessanten Anfrage eines Kunden gearbeitet. Die Ergebnisse könnten auch für andere relevant sein.
Die Problemstellung war:
Es besteht seitens des Kunden die Anforderung, dass WLAN Verbindungen nur dann aktiviert werden dürfen, wenn keine Ethernet Verbindung vorhanden ist. Dieses kann erreicht werden durch zum Beispiel: Features im BIOS von verschiedenen Herstellern oder auch 3rd Party Software. In Windows XP, Windows Vista und Windows 7 gibt es keine Möglichkeit, auf dieses Verhalten Einfluss zu nehmen. Mit Windows 8 und Windows Server 2012 gibt es ein sehr ähnliches Feature, das per default aktiv ist und mittels Gruppenrichtlinien gesteuert werden kann.
Die Policy nennt sich “Minimize the number of simultaneous connections to the Internet or a Windows Domain” und man findet sie wie folgt:
Nun zurück zu dem eigentlichen Problem: Sobald das Ethernet Kabel eines Windows 7 Clients getrennt wurde, wurde die WiFi Verbindung nicht automatisch hergestellt. Wenn man jedoch die WLAN Netzwerkkarte über ncpa.cpl deaktiviert und anschließend wieder aktiviert, so funktioniert die WLAN Verbindung wieder einwandfrei. Der Kunde setzte eine BIOS basierende Lösung ein, um den automatischen Wechsel von Ethernet auf WLAN zu erreichen.
Um der Ursache auf die Schliche zu kommen, haben wir ein detailliertes Logging aus einer privilegierten cmd.exe aktiviert.
Die Syntax lautet: 'netsh trace start wlan_dbg globallevel=0xff capture=yes persistent=yes tracefile=c:\wlan.etl' .
Sobald man den Fehler reproduziert hat, muss man das Logging mittels 'netsh trace stop‘ beenden.
Dabei wird eine Datei c:\wlan.etl erstellt, welche man mit dem Microsoft Netzwerk Monitor 3.4 öffnen kann. Man sollte allerdings die Parser im Netzwerk Monitor 3.4 noch auf ‚Windows‘ stellen.
Bei der Analyse der Daten ist dann folgende Fehlermeldung aufgefallen:
N802_MicrosoftWindowsNWiFi:CallAdapterSync Error: 2147483653 (0x80000005) OID 234946937 (0xE010179)
Um sich die Suche ein wenig zu erleichtern, kann man folgenden Display Filter verwenden:
N802_MicrosoftWindowsNWiFi.CallAdapterSync.Status == 0x80000005
Doch was bedeutet der Fehler eigentlich? Der Error Code 0x80000005 steht für ERROR_ACCESS_DENIED. Die Tatsache, dass dieser bei der Funktion CallAdapterSync auftritt, zeigt dass es ein Problem gab, Daten über den NDIS Layer zu versenden. Ein Treiber hat die Operation verweigert und den Aufruf blockiert. Nur welcher?
Letztlich war die Ursache, dass eine VPN Software eines Drittanbieters installiert war, welche eine virtuelle Netzwerkkarte erstellt hatte. Diese Netzwerkkarte wurde als Ethernet Karte betrachtet und somit konnte die WLAN Verbindung aufgrund des aktivierten BIOS Features nicht korrekt und automatisch aktiviert werden.
Den Typ bzw. das Medium einer Netzwerkkarte kann man über folgende OID abfragen:
OID_GEN_PHYSICAL_MEDIUM
https://msdn.microsoft.com/en-us/library/windows/hardware/ff569621(v=vs.85).aspx
Was sind OID’s? NDIS definiert Object Identifier (OID) Werte, um die Parameter eines Adapters zu identifizieren.
https://msdn.microsoft.com/de-de/library/windows/hardware/ff566707(v=vs.85).aspx
Eine Deinstallation der VPN Client Software hat das Problem nicht gelöst. Wenn man den Windows 7 Client ohne die VPN Software installierte, ist der Fehler nicht mehr aufgetreten. Der Kunde hat nun eine Support Anfrage bei dem Anbieter der VPN Client Software eröffnet.
Eine alternative Lösungsmöglichkeit stellt Software dar, welche entsprechende Ausnahmen für bestimmte Adapter definieren kann, um den problemlosen und automatischen Wechsel von Ethernet auf WLAN zu ermöglichen. Somit kann man solche Inkompatibilitäten adressieren und den oben beschriebenen Problemen aus dem Weg gehen.
Aus rechtlichen Gründen kann ich hier den Namen des Herstellers der VPN Client Software oder Links zu Lösungsanbietern nicht benennen. Ich hoffe, dass der Blog trotzdem für Euch interessant ist. Über ein Feedback würde ich mich sehr freuen.
Euer Frank
Comments
Anonymous
January 01, 2003
Danke für den interessanten Artikel, Frank!Anonymous
July 25, 2013
The comment has been removed