Probleme beim Wechsel Ethernet - WIFI

Probleme beim Wechsel Ethernet - WIFI

  • Comments 2
  • Likes

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:

GPO_WIFI

 

 

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.
clip_image005

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.

clip_image006

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

clip_image008

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
http://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.
http://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
  • Danke für den interessanten Artikel, Frank!

  • Hallo Frank,

    danke für den coolen Artikel!

    Ich hatte diese Anfrage auch schon bei einem großen Kunden der das einsetzt und auch hier kam es zu einem ähnlichen Verhalten welches ich aber nicht so bis ins Detail wie Du analysiert habe.

    Auch hier war es ein 3rd Party VPN-Client, dierser hatte auch selbst die Funktion entweder WLAN, oder LAN per Software zu blocken.

    Da dies nicht zu 100% funktionierte und oft in einem deaktivierten Netzwerkadapter resultierte (welchen die User ohne Admincredentials nicht wieder aktivieren konnten) entschied man sich das ganze durch das Bios der Notebooks zu lösen und die Funktion im 3rd Party VPN-Client abzuschalten.

    Dabei kam es zu einem ähnlichen Verhalten wie von Dir oben beschrieben.

    Es ist echt cool dass auch über solche Features hier geschrieben wird und ein weiterer Grund auf Windows 8 zu wechseln und das OS die Arbeit machen zu lassen :)

    Gruß

    Wolfgang

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment