Problembehandlung bei Device.Network-Tests

Problembehandlung bei Device.Network-Tests

Führen Sie die folgenden Schritte aus, um Probleme zu beheben, die bei Device.Network-Tests auftreten:

1. Weitere Informationen finden Sie unter Problembehandlung bei Windows HLK-Testfehlern.

   Informieren Sie sich in einem der folgenden Themen zum jeweiligen Typ von getestetem Netzwerkprodukt oder Feature:

   • Testvoraussetzungen für IPsec Task Offload v2

   • LAN-Testvoraussetzungen

   • Testvoraussetzungen für mobiles Breitband

   • Testvoraussetzungen für Router (nicht drahtlos)

   • Testvoraussetzungen für WLAN (802.11)

   • Testvoraussetzungen für drahtlose Router

2. Informationen zu aktuellen Testproblemen finden Sie in den Versionshinweisen zu Windows HLK.

3. Suchen Sie verwendbare Informationen zu einem Testfehler im Windows HLK Studio-Testprotokoll. Wenn Sie verwendbare Informationen finden, beheben Sie das Problem, und führen Sie den Test erneut aus.

Bekannte IPsec-Testprobleme

Wenn der Windows HLK-Controller keine Verbindung mit Clients herstellen kann, führen Sie die folgenden Schritte aus:

1. Mit dem ersten Testfall soll sichergestellt werden, dass das Setup richtig ist. Dabei wird lediglich die Konnektivität des öffentlichen und privaten Netzwerks überprüft. Wenn dieser Test zu einem Fehler führt, gibt es ein Problem mit der Testeinrichtung.

2. Überprüfen Sie, ob die Datei „config.dat“ im Verzeichnis „%SystemDrive%\IPsecTestKit\IPsecScenario\“ enthalten ist und die richtigen IP-Adressen für den Controller und die Clients enthält. Diese Datei wird automatisch generiert, aber in bestimmten Fällen wie DNS-Auflösungsfehlern kann die Datei „config.dat“ falsche Daten enthalten oder vollständig fehlen. Verwenden Sie das im Abschnitt „Testeinrichtung“ beschriebene Format, um die Datei „config.dat“ zu überprüfen.

3. Überprüfen Sie, ob Firewallausnahmen für „IPsecControl.exe“ und „IPsecScenario.exe“ eingerichtet wurden.

4. Stellen Sie sicher, dass nach dem Ausführen der Setupskripts die IPsec Offload V2-Schnittstellen erfolgreich in „Test1“ umbenannt werden.

„Genconfig_phase2.vbs“ generiert möglicherweise nicht die erforderlichen CMD-Dateien, wenn nur ein Standardgateway für den Nachrichtenadapter vorhanden ist. Wenn Ihr DHCP-Server IP V6 nicht unterstützt, erhalten Sie möglicherweise nur eine IP V6-Standardgatewayadresse.

Ausführen einzelner Testvarianten

In bestimmten Fällen, in denen Tests Fehler verursachen, führen Sie eine einzelne Testvariante aus, anstatt die gesamte Suite erneut auszuführen. Gehen Sie hierzu folgendermaßen vor:

1. Stellen Sie sicher, dass die Sitzungen von „IPsecScenario.exe“ auf allen Clients ausgeführt werden.

2. Kopieren Sie einzelne Varianten, damit sie aus „OffloadV2_logoTests.cmd“ ausgeführt werden, und führen Sie sie in einem neuen Befehlsfenster aus (%SYSTEMDRIVE%\IPsecTestKit\IPSecscenario\Controller).

Troubleshooting LAN (Ethernet) Testing

Der IPsec-Testauftrag kann aufgrund von Problemen mit verwandten LAN-Testaufträgen zu Fehlern führen. Weitere Informationen hierzu finden Sie im folgenden Abschnitt.

Bekannte Probleme bei LAN-Tests (Ethernet)

Problem	Details
Die Testaufträge „IPsec Offloadv2 logo verification (Win7)“ bleiben im Status „Scheduler“ und werden nie ausgeführt.	Dieses Problem wird in der Regel durch verschiedene Kommunikationsprobleme zwischen dem DTM-Client und dem Controller verursacht. Sie können überprüfen, ob der „Zeitpunkt des letzten Takts“ in der Nähe der aktuellen Uhrzeit liegt. Um den DTM-Client zu erzwingen, der einen Takt meldet, können Sie den Status des Computers in DTM Studio manuell in Zurücksetzen oder Unsicher ändern und dann warten, bis sich der Status des Computers in „Normal“ ändert. Nachdem der Status aller Computer, die zum Ausführen des Auftrags erforderlich sind, in Normal geändert wurde, wird der Auftrag auf den DTM-Clients geplant. Wenn sich der Computerstatus in Debuggen ändert, überprüfen Sie, ob der DTM-Clientcomputer weiterhin reagiert. Manchmal lautet der Computerstatus Normal, und der Takt stimmt, aber der Auftrag wird trotzdem nicht ausgeführt. Dies wird sehr wahrscheinlich dadurch verursacht, dass die Firewall oder IPsec die Kommunikation zwischen dem DTM-Client und dem Controller blockiert. Stellen Sie sicher, dass der DTM-Client und der Controller dieselbe IPsec-Konfiguration aufweisen. Wenn IPsec auf dem Client aktiviert ist, aber auf dem Controller deaktiviert ist (oder umgekehrt), wird der Auftrag nicht geplant. Der DTM-Client ist für die Verwendung mit einer Firewall konzipiert, aber manchmal blockiert die Firewall den normalen Datenverkehr zwischen dem Client und dem Controller.
Im Testprotokoll wird dann die folgende Fehlermeldung angezeigt: „Der Auftrag xxx erfordert die Auswahl eines Geräts, nicht eines Treibers“, wenn Sie auf „Informationen hinzufügen“ klicken.	Dieser Fehler tritt auf, da Sie in der Gerätekonsole einen Treiber ausgewählt haben, nicht ein Testgerät, um den Testauftrag auszuführen. Wenn Sie unter dem Treiber in der Gerätekonsole kein Gerät finden können, stimmen die INF-Datei und die Treiberdateien, die Sie während der Logoübermittlung bereitgestellt haben, nicht mit der tatsächlichen INF-Datei und den Treiberdateien auf dem DTM-Client überein. Ändern Sie Ihre INF-Datei und die Treiberdateien in die tatsächliche INF-Datei und die Treiberdateien, die auf dem DTM-Client installiert sind.
In der „Gerätekonsole“ wird kein Auftrag „IPsec Offloadv2 logo verification (Win7)“ angezeigt.	Stellen Sie sicher, dass Ihr Gerät ein Ethernetgerät (LAN) ist, und melden Sie als Medientyp NdisMedium802_3 an NDIS. Dieser Fehler tritt manchmal auf, wenn die vom DTM-Client gemeldeten Hardwareinformationen unvollständig sind. Um dieses Problem zu beheben, versuchen Sie, den DTM-Clientcomputer neu zu starten und die Ansicht der Gerätekonsole zu aktualisieren. Wenn dies nicht funktioniert, versuchen Sie, den wttsvc-Dienst auf dem DTM-Client zu beenden und neu zu starten, und aktualisieren Sie dann die Ansicht der Gerätekonsole.
Der Test „Ethernet - NDISTest 6.0 (priority)“ führt bei der Assertion „2c_priority and Directed Packets - NdisSendPackets“ zu einem Fehler beim Abrufen der Testergebnisse für den Testnetzwerkadapter.	Dieses Problem kann auftreten, wenn der Netzwerkswitch Prioritätsbits falsch entfernt. Um sich zu vergewissern, dass dieses Problem tatsächlich vom Netzwerkswitch verursacht wird, testen Sie den Adapter, indem Sie den Switch entfernen und die Kabel direkt anschließen. Dazu können Sie eine alternative Testkonfiguration verwenden. Diese Testkonfiguration kann nur von Geräten verwendet werden, die Chimney nicht unterstützen (TCP Offload), da für diese Geräte das lokale Supportgerät erforderlich ist. Entfernen Sie das lokale Supportgerät und den Testnetzwerkswitch, und verbinden Sie das lokale Testgerät direkt mit dem Remotesupportgerät. Wenn der Test dann bestanden wird, genügt dies für die Zertifizierung. Sie sollten aber mit dem Switchhersteller zusammenarbeiten, um die Switchkonfiguration zu korrigieren.
Der Auftrag „Ethernet - NDISTest 6.5 (WoL and PM)“ kann erwartbar bei Geräten innerhalb der Netzwerkpaketassertion „Send a FAKE LLMNRv4“ einen Fehler verursachen, der angibt, dass der Computer nicht ordnungsgemäß funktioniert.	Um zu ermitteln, ob Ihr Gerät diesen erwartbaren Fehler verursacht, heben Sie nur auf dem Remotegerät die Protokollbindung auf. Wenn das Problem damit nicht behoben wird, erstellen Sie einen Supportincident.

Hinweis

Für die Problembehandlung beim NDISTest (6.0 oder 6.5) fügen Sie einen Debugger an den Testcomputer an.

Bekannte Probleme beim mobilen Breitbandtest

In der folgenden Liste werden einige allgemeine Tipps zur Problembehandlung bei Test für das mobile Breitband beschrieben:

Änderungen, die an Geräten auf DTM-Clientcomputern vorgenommen wurden, werden in DTM Studio nicht angezeigt. So wird beispielsweise erwartet, dass sich der Computer im Status „Bereit“ befindet, was aber nicht zutrifft.

1. Öffnen Sie auf dem Clientcomputer ein Eingabeaufforderungsfenster, und führen Sie dann net stop wttsvc aus.

2. Führen Sie net start wttsvc aus. Mit diesem Befehl aktualisieren Sie das Verzeichnis „C:\wtt\JobsWorkingDir\AssetCfg\Log\Log\“.

3. Aktualisieren Sie die Gerätekonsole in DTM Studio. Es kann mehrere Minuten dauern, bis der DTM-Controller den Clientcomputer auf Änderungen an der Geräteliste abgefragt hat.

Computer für den Computerpool wurden nicht gefunden.

1. Öffnen Sie das Fenster Auftragsmonitor in DTM Studio.

2. Klicken Sie oben auf dem Bildschirm auf die Schaltfläche Abfragegenerator anzeigen.

3. Klicken Sie auf die Registerkarte Computerabfrage.

4. Definieren Sie Suchparameter für die Zielcomputer. In der Regel legen Sie eine einzelne Regel fest, z. B. „DataStore gleich 'Controllername'“.

5. Klicken Sie mit der rechten Maustaste auf die Regel, die Sie gerade definiert haben, und klicken Sie dann auf Ausführen. Die Liste Computer unterhalb der Abfragefelder wird mit einer umfangreichen Liste von Computern gefüllt.

6. Ziehen Sie alle Computer in der Liste Computer in den neu erstellten Computerpool.

Computer scheinen keine Aufträge auszuführen, die für sie geplant sind.

1. Öffnen Sie das Fenster Auftragsmonitor in DTM Studio.

2. Wählen Sie auf der Registerkarte Computerpool den Computerpool aus, der die Aufträge ausführen sollte.

3. Überprüfen Sie für jeden Computer in diesem Pool, ob der Status Bereit lautet.

4. Wenn der Status eines Computers nicht Bereit lautet, klicken Sie mit der rechten Maustaste auf den Computer, zeigen Sie auf Status ändern, und klicken Sie dann auf Zurücksetzen.

5. Aktualisieren Sie nach einigen Minuten den Bildschirm. Der Status sollte in Bereit geändert werden.

6. Planen und starten Sie die Aufträge erneut.

Voraussetzungen für Tests von Netzwerksicherheitssoftware

Für die Tests von Netzwerksicherheitssoftware (TransitionTechnologies_Tests und WindowsFilteringPlatform_Tests) müssen die Sparta-Miniporttreiber installiert und ordnungsgemäß konfiguriert sein. Die Sparta-Miniporttreiber werden bei jeder Testausführung installiert. Sie können jedoch überprüfen, ob sie vorhanden sind, indem Sie eine Eingabeaufforderung öffnen und IPConfig.exe /all eingeben. Es sollten vier neue Sparta-Schnittstellen mit den Bezeichnungen „Sparta Miniport Primary“, „Sparta Miniport Secondary“, „Sparta Miniport Tertiary“ und „Sparta Miniport Quaternary“ angezeigt werden.

Bekannte Probleme bei Routertests

Derzeit gibt es keine bekannten Routertestprobleme.

Bekannte Probleme bei WLAN-Tests (802.11)

In der folgenden Liste werden einige allgemeine Tipps zur Problembehandlung bei WLAN-Test beschrieben:

Änderungen, die an Geräten auf DTM-Clientcomputern vorgenommen wurden, werden in DTM Studio nicht angezeigt. So wird beispielsweise erwartet, dass sich der Computer im Status „Bereit“ befindet, was aber nicht zutrifft.

1. Öffnen Sie auf dem Clientcomputer ein Eingabeaufforderungsfenster, und führen Sie dann net stop wttsvc. aus.

2. Führen Sie net start wttsvc aus. Mit diesem Befehl aktualisieren Sie das Verzeichnis „C:\wtt\JobsWorkingDir\AssetCfg\Log\Log\“.

3. Aktualisieren Sie die Gerätekonsole in DTM Studio. Es kann mehrere Minuten dauern, bis der DTM-Controller den Clientcomputer auf Änderungen an der Geräteliste abgefragt hat.

Computer für den Computerpool wurden nicht gefunden.

1. Öffnen Sie das Fenster Auftragsmonitor in DTM Studio.

2. Wählen Sie oben auf dem Bildschirm die Schaltfläche Abfrage-Generator anzeigen aus.

3. Klicken Sie auf die Registerkarte Computerabfrage.

4. Definieren Sie Suchparameter für die Computer, nach denen Sie suchen. In der Regel können Sie eine einzelne Regel festlegen, z. B. „DataStore gleich 'Controllername'“.

5. Klicken Sie mit der rechten Maustaste auf die Regel, die Sie gerade definiert haben, und klicken Sie dann auf Ausführen. Die Liste „Computer“ unterhalb der von Ihnen definierten Abfragefelder sollte mit einer umfangreichen Liste von Computern gefüllt werden.

6. Ziehen Sie alle Computer in der Liste Computer in den neu erstellten Computerpool.

Computer scheinen keine Aufträge auszuführen, die für sie geplant sind.

1. Öffnen Sie das Fenster Auftragsmonitor in DTM Studio.

2. Wählen Sie auf der Registerkarte Computerpool den Computerpool aus, der die Aufträge ausführen sollte.

3. Überprüfen Sie für jeden Computer in diesem Pool, ob der Status Bereit lautet.

4. Wenn der Status eines Computers nicht Bereit lautet, klicken Sie mit der rechten Maustaste auf den Computer, zeigen Sie auf Status ändern, und klicken Sie dann auf Zurücksetzen.

5. Aktualisieren Sie nach einigen Minuten den Bildschirm. Der Status sollte in Bereit geändert werden.

6. Planen und starten Sie die Aufträge erneut.

Probleme beim Installieren des Test-SoftAP-Treibers in der Topologie: Geräte-Manager meldet Code 52

Installieren Sie den x64-Test-SoftAP-Treiber nicht vor dem DTM-Client. Bei der Installation des DTM-Clients wird auch das Stammzertifikat installiert. Da das Signieren des Test-SoftAP-Treibers von der Installation des Stammzertifikats abhängt, meldet der Geräte-Manager den Gerätecode 52.

Konfigurieren von NDISTest für die eigenständige Ausführung

Durch die separate Installation von NDISTest und DTM Studio können Sie einzelne Tests ausführen. DUT, SUT und Test-SoftAP müssen so konfiguriert werden, dass eine eigenständige Ausführung möglich ist.

Hinweis

Auf allen Testcomputern muss dieselbe Prozessorarchitektur verwendet werden.

Hinweis

Für die Problembehandlung beim NDISTest versuchen Sie, einen Debugger an den Testcomputer anzufügen.

Konfigurieren eines getesteten Supportgeräts (Support Device Under Test, SUT)

1. Kopieren Sie alle NDISTest-Binärdateien und -Unterverzeichnisse vom folgenden DTM-Controller:

   \\<ControllerMachine]>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\

   <ControllerMachine> ist der Name des DTM-Controllercomputers und <architecture> ist entweder x86 (für x86-basierte Prozessoren) oder amd64 (für x64-basierte Prozessoren).

2. Starten Sie „NDISTest.exe“ aus dem Installationsverzeichnis. Wenn das Hauptformular geöffnet wird, wählen Sie Server im Menü File (Datei) aus, um das Serverformular zu starten.

3. Wählen Sie das Nachrichtengerät in der Liste Message Device (Nachrichtengerät) aus. Dieses Gerät muss IP-fähig sein und sich im selben Subnetz wie das Clientnachrichtengerät befinden, das später eingerichtet wird.

4. Wählen Sie die SUTs in Support Devices (Supportgeräte) aus. Das auf diesem Server ausgewählte Supportgerät ist nach dem Start des Servers für den Client sichtbar.

5. Wählen Sie den Auftrag „server“ in Jobs (Aufträge) aus. Dies ist der serverseitige Test, der gestartet wird, nachdem Sie auf die Startschaltfläche geklickt haben.

Nachdem alle Optionen ausgewählt wurden, klicken Sie auf Start, um den Server zu starten.

Konfigurieren eines Test-SoftAP (Testsoftwarezugriffspunkt)

1. Kopieren Sie alle NDISTest-Binärdateien und -Unterverzeichnisse vom folgenden DTM-Controller:

   \\<ControllerMachine]>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\

   <ControllerMachine> ist der Name des DTM-Controllercomputers und <architecture> ist entweder x86 (für x86-basierte Prozessoren) oder amd64 (für x64-basierte Prozessoren).

2. Installieren Sie den SoftAP-Treiber für beide Atheros-WLAN-Geräte auf dem Test-SoftAP. Sie können diesen Treiber im Geräte-Manager installieren, den Sie über eine Eingabeaufforderung mit devmgmt.msc öffnen können. Führen Sie den folgenden Schritt aus:

   Installieren Sie im Geräte-Manager den Treiber für SoftAP-Stationen von:

   \\<ControllerMachine]>\Tests\<architecture>\nttest\nettest\ndis\NDISTest.net\SoftAPMiniport\

   <ControllerMachine> ist der Name des DTM-Controllercomputers und <architecture> ist entweder x86 (für x86-basierte Prozessoren) oder amd64 (für x64-basierte Prozessoren). Diese hängt von der Prozessorarchitektur des DTM-Clientcomputers mit den SoftAP-Geräten ab.

3. Starten Sie „NDISTest.exe“ aus dem Installationsverzeichnis. Wenn das Hauptformular geöffnet wird, wählen Sie Server im Menü File (Datei) aus, um das Serverformular zu starten.

4. Wählen Sie das Nachrichtengerät in der Liste Message Device (Nachrichtengerät) aus. Dieses Gerät muss IP-fähig sein und sich im selben Subnetz wie das Clientnachrichtengerät befinden, das später eingerichtet wird.

5. Wählen Sie die AP-Geräte in AP Devices (AP-Geräte) aus. Die auf diesem Server ausgewählten AP-Geräte sind nach dem Start des Servers für den Client sichtbar.

6. Wählen Sie den Auftrag „server“ in Jobs (Aufträge) aus. Dies ist der serverseitige Test, der gestartet wird, nachdem Sie auf die Startschaltfläche geklickt haben.

Nachdem alle Optionen ausgewählt wurden, klicken Sie auf Start, um den Server zu starten.

Konfigurieren des getesteten Geräts (Device Under Test, DUT)

1. Kopieren Sie alle NDISTest-Binärdateien und -Unterverzeichnisse vom folgenden DTM-Controller:

   \\<ControllerMachine>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\

   <ControllerMachine> ist der Name des DTM-Controllercomputers und <architecture> ist entweder x86 (für x86-basierte Prozessoren) oder amd64 (für x64-basierte Prozessoren).

2. Starten Sie „NDISTest.exe“ aus dem Installationsverzeichnis. Wenn das Hauptformular geöffnet wird, wählen Sie Client im Menü File (Datei) aus, um das Clientformular zu starten.

3. Wählen Sie das Testziel in der Liste Test Target (Testziel) aus. Bei Netzwerkgeräten sollte dieses Testziel Miniport sein.

4. Wählen Sie das Testgerät in der Liste Test Device (Testgerät) aus. Dabei muss es sich um ein herstellerspezifisches Testgerät handeln.

5. Wählen Sie ein Nachrichtengerät in der Liste Message Device (Nachrichtengerät) aus. Dabei sollte es sich um ein IP-aktiviertes Gerät handeln, das sich im selben Subnetz wie das Servernachrichtengerät befindet. Nachdem das Nachrichtengerät ausgewählt wurde, sollte der Abschnitt mit dem AP-Gerät angezeigt werden, und das Server-AP-Gerät sollte in der Liste enthalten sein.

6. Wählen Sie ein Supportgerät in Support Devices (Supportgeräte) aus. Dabei muss es sich um ein herstellerspezifisches Supportgerät handeln.

7. Wählen Sie ein AP-Gerät in AP Devices (AP-Geräte) aus. Dabei muss es sich um das AP-Gerät handeln, das auf der Serverseite ausgewählt wurde.

8. Wählen Sie die Tests im Abschnitt Jobs (Aufträge) aus, die nach dem Starten des Clients ausgeführt werden.

Nachdem alle Optionen ausgewählt wurden, klicken Sie auf Start, um den Client zu starten. Die Ausführung aller ausgewählten Aufträge wird gestartet. Die Testergebnisse werden auf dem Client im folgenden Protokollierungsunterordner gespeichert:

<NDISTestRootFolder>/logs/<AdapterName>/

Konfigurieren der Clientpaketerfassung

1. Konfigurieren Sie eine Testtopologie für die eigenständige Ausführung. Weitere Informationen finden Sie unter „Konfigurieren von NDISTest für die eigenständige Ausführung.“

2. Richten Sie ein zweites SUT ein. Weitere Informationen finden Sie unter „Konfigurieren eines zu testenden Supportgeräts (SUT).“

3. Starten Sie „NDISTest.exe“ aus dem Installationsverzeichnis. Wenn das Hauptformular geöffnet wird, wählen Sie Debug im Menü View (Ansicht) aus, um den Abschnitt Packet Capture (Paketerfassung) auf dem Client zu starten.

4. Wählen Sie ein Erfassungsgerät in Packet Capture (Paketerfassung) aus. Dabei muss es sich um ein Supportgerät handeln, das auf der Serverseite ausgewählt wurde.

5. Wählen Sie die Tests im Abschnitt Jobs (Aufträge) aus, die nach dem Starten des Clients ausgeführt werden.

6. Nachdem alle Optionen ausgewählt wurden, klicken Sie auf Start, um den Client zu starten.

7. Die Paketerfassungen zu den einzelnen Tests werden auf dem Server mit dem Erfassungsgerät generiert. Die Protokolle befinden sich im folgenden Protokollierungsunterordner:

   <NDISTestRootFolder>/logs/<AdapterName>/

Problembehandlung, wenn der Abschnitt „Packet Capture“ (Paketerfassung) nicht auf dem Client angezeigt wird

Stellen Sie sicher, dass die Benutzeroberfläche des Nachrichtencenters geschlossen ist. Wenn die NDISTest-Benutzeroberfläche nicht maximiert wurde, ist der Abschnitt Packet Capture (Paketerfassung) möglicherweise hinter der Benutzeroberfläche des Nachrichtencenters verborgen.

Bekannte Probleme mit WLAN-Routertests

Dieser Tipp hilft Ihnen beim Testen der Fähigkeit eines Computers, höhere Bitraten über eine Ethernetverbindung zu senden (also eine Computerüberprüfung).

Für dieses Testverfahren richten Sie zwei Computer wie in der folgenden Abbildung dargestellt ein:

1. Richten Sie die Hardware wie unten dargestellt nur mit einer Ethernetverbindung ein.

2. Weisen Sie Computer S eine statische IP-Adresse zu.

   Beispiel: 10.0.0.2

3. Weisen Sie Computer C eine statische IP-Adresse zu.

   Beispiel: 10.0.0.3

4. Öffnen Sie auf Computer C eine Eingabeaufforderung mit erhöhten Rechten, und führen Sie den folgenden Befehl aus:

   stats.exe -z DISCARD -i 20 -x 50 -y 30 -r 20000000 -c 3600 -l -h -u

5. Öffnen Sie auf Computer S eine Eingabeaufforderung mit erhöhten Rechten, und führen Sie den folgenden Befehl aus:

   stats.exe -d 10.0.0.3 -r 20000000 -c 4200 -l -h -u

6. Überprüfen Sie die Ausgaben von Schritt 4 und Schritt 5.

Wenn die Ausgabe von Schritt 4 oder Schritt 5 Fehler enthält, können Ihre Computer bestimmte Bitraten nicht mit drahtlosen Adaptern übermitteln.

Wenn Sie manuell ein Funknetzwerkprofil hinzufügen möchten, können Sie dazu den Befehl „netsh“ verwenden.

So fügen Sie z. B. das Funknetzwerkprofil „802_11a_wpa-psk.xml“ hinzu

1. Klicken Sie auf Start und auf Ausführen, und geben Sie dann cmd.exe ein.

2. Geben Sie netsh wlan add profile filename=802_11a_wpa-psk.xml i=\* ein.

3. Klicken Sie auf OK.

Hinweis

Stellen Sie sicher, dass die XML-Datei des Funknetzwerkprofils im aktuellen Verzeichnis enthalten ist, oder geben Sie den vollständigen Pfad an.

Verwandte Themen

Device.Network-Tests

Problembehandlung bei Windows HLK