Paketmitschnitt unter Windows in der Praxis — pktmon, netsh trace und Wireshark wählen

„Die Kommunikation der Geschäftsanwendung scheitert ein paar Mal im Monat. Das Log sagt nur Timeout. Auf der Serverseite gibt es keinen Fehler, und die Reproduktionsbedingungen sind unklar.“ In der Untersuchung von Kommunikationsstörungen begegnet das häufig.

Was Sie dann wissen wollen, ist, ob die Verbindung nicht zustande kam oder nach dem Verbinden die Antwort ausblieb. Auch beim selben Timeout unterscheidet sich der nächste Untersuchungsort.

Im Anwendungslog bleibt nur, was die App „zu schreiben beschloss“. Allein das Ergebnis Timeout unterscheidet nicht, ob SYN keine Antwort bekam, der Server nach hergestellter Verbindung schwieg oder RST schnitt.

Diese eine Schicht tiefer, die Pakete, die wirklich über die Leitung gingen, zu untersuchen, ist Paketmitschnitt. Gegenüber Process Monitor, der Datei- und Registrierungszugriffe eine Schicht tiefer sieht, sieht dieser die Kommunikation eine Schicht tiefer. Wollen Sie bis dahin gehen, ob das Paket das Ziel erreichte, wird der beidseitige Mitschnitt in Kapitel 7 wichtig.

flowchart TB
    accTitle: Die Pakete eine Schicht unter dem Anwendungslog
    accDescr: Im Anwendungslog bleibt nur, was zu schreiben beschlossen wurde; ob SYN keine Antwort bekam, nach dem Herstellen geschwiegen wurde, RST schnitt oder es überhaupt ankam, bleibt nur in den Paketen, die wirklich über die Leitung gingen
    log["Anwendungslog"] --> dec["Nur was zu schreiben beschlossen wurde bleibt"]
    dec --> to["Das Ergebnis ist das eine Wort Timeout"]
    to -->|eine Schicht tiefer sehen| pkt["Pakete, die wirklich über die Leitung gingen"]
    pkt --> q1["Keine Antwort auf SYN?"]
    pkt --> q2["Stille nach dem Herstellen?"]
    pkt --> q3["Mit RST getrennt?"]
    pkt --> q4["Hat es das Ziel erreicht?"]

Abbildung 1: Das Log behält nur das Ergebnis; die Aufschlüsselung eines Timeouts bleibt nur in den Paketen eine Schicht tiefer.

Auch wenn Sie „Wireshark auf dem Kundenserver nicht installieren dürfen“, müssen Sie den Mitschnitt nicht aufgeben. Auch ohne Zusatzsoftware durch Änderungskontrolle oder Sicherheitsrichtlinie hat Windows die Standardmittel pktmon und netsh trace.

Die Grundlage ist die Aufteilung, vor Ort mit dem Standardwerkzeug aufzunehmen und auf dem eigenen Rechner in Wireshark zu lesen. Denken Sie Mitschnitt und Analyse als getrennte Arbeiten, kommen Sie auch auf einem install-gesperrten Standort voran.

Dieser Artikel richtet sich an IT-Verantwortliche in kleinen und mittleren Unternehmen und an Entwickler von Windows-Apps. Er ordnet die Wahl zwischen pktmon, netsh trace und Wireshark und das praktische Verfahren für jedes. Loopback-Fallen, die Entscheidung, auf Client oder Server mitzuschneiden, der Umgang damit, dass TLS die Nutzlast verbirgt, und der Abgleich mit dem Anwendungslog werden aus Primärquellen Stand August 2026 behandelt.

Von dem aus lesen, was nicht stimmt

Wer zum ersten Mal liest, sollte in Kapitel 2 das Werkzeug wählen, in 3 bis 4 aufnehmen und in 5 lesen. Die Kapitel 6 bis 8 sind Hinweise zu Aufnahmebedingungen und Beobachtungsbereich, Kapitel 9 das Verfahren, mit dem Anwendungslog zum Schluss zu kommen.

1. Zuerst das Fazit

Mitschnitt und Analyse dürfen Sie verschiedenen Werkzeugen überlassen

Vor Ort nehmen Sie mit pktmon oder netsh trace auf, wandeln nach pcapng und analysieren in Wireshark auf dem eigenen Rechner. Beide geben ETL aus, deshalb öffnet Wireshark sie nicht unverändert. Für pktmon nutzen Sie pktmon etl2pcap, für netsh trace Microsofts Open-Source-Werkzeug etl2pcapng.¹²

Die Werkzeugwahl ist zuerst pktmon, wenn das nicht reicht netsh trace, Protokollanalyse Wireshark. Auch Microsofts Untersuchungsleitfaden zeigt diesen Fluss.³

Vor dem Mitschnitt festlegen, welche Information bleibt und wo beobachtet wird

pktmon ist ab Windows 10 / Windows Server 2019 standardmäßig enthalten und wird in vier Schritten genutzt: Filter registrieren → starten → stoppen → wandeln. Die eigene Stärke ist, wo im Stapel das Paket verworfen wurde und der Drop-Grund. Standardmäßig bleiben jedoch nur die ersten 128 Bytes. Wollen Sie bis zum Inhalt lesen, geben Sie beim Start --pkt-size 0 an.⁴⁵⁶

netsh trace ist das ältere Standardwerkzeug. Als Szenario bündelt es ETW-Provider und kann Pakete und interne Windows-Ereignisse aufnehmen. Für Mitschnitt über einen Neustart nutzen Sie persistent=yes.⁷⁸

Ziele an localhost gehen nicht durch eine physische NIC und erscheinen nicht im Mitschnitt eines physischen Adapters. Nutzen Sie den Loopback-Adapter von Npcap oder die Aufnahme von pktmon im Stapel.⁹

Beobachtbare Fakten und den Umgang mit der Datei getrennt denken

Auch wenn TLS den Inhalt verbirgt, lassen sich Verbindungsaufbau, Erfolg des TLS-Handshake, RST und welche Seite schwieg untersuchen. Entschlüsselung über SSLKEYLOGFILE ist ein Mittel nur für die Entwicklungsumgebung.¹⁰

Andererseits enthält die Mitschnittdatei die Kommunikation selbst. Unter der Voraussetzung, dass Anmeldedaten und personenbezogene Daten enthalten sein können, nehmen Sie Ziel und Zeitraum minimal und bauen das Einengen vor der Weitergabe an Dritte in das Aufnahmeverfahren ein.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (21 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Die drei Mitschnitt-Werkzeuge und wie man wählt

Das Auswahlkriterium ist „was darf vor Ort hinein“ und „was außer Paketen soll bleiben“. Zuerst vergleichen Sie die Rollen der drei Werkzeuge.

pktmon und netsh trace „aufnehmen“, Wireshark „lesen“ ist die leicht zu denkende Aufteilung. Wireshark kann auch mitschneiden, auf einem Standort ohne Installation jedoch nicht.

Die ETL der Standardwerkzeuge lässt sich auch in Text wandeln und lesen. Ohne Anzeigefilter und TCP-Analyse visuell zu lesen, kommt die Untersuchung jedoch weniger voran als die Wandlung nach pcapng und die Analyse in Wireshark.

flowchart TB
    accTitle: Aufnehmen mit dem Standardwerkzeug, lesen mit Wireshark
    accDescr: Vor Ort nehmen pktmon oder netsh trace ETL auf, jedes Wandlungswerkzeug macht pcapng daraus, die Analyse läuft in Wireshark auf dem eigenen Rechner
    pk["pktmon (Standard)"] --> etla["ETL-Datei"]
    ns["netsh trace (Standard)"] --> etlb["ETL+.cab"]
    etla -->|pktmon etl2pcap| pcap["pcapng"]
    etlb -->|etl2pcapng| pcap
    pcap --> ws["Analyse in Wireshark auf dem eigenen Rechner"]

Abbildung 2: Vor Ort nehmen Standardwerkzeuge ETL auf, nach pcapng gewandelt lesen Sie in Wireshark auf dem eigenen Rechner.

Auch Microsofts Leitfaden zur Untersuchung von Paketverlust zeigt dasselbe Bild: zuerst mit pktmon aufnehmen und die Ursache eingrenzen, wenn das nicht reicht zu Komponenten-Traces wie netsh trace start scenario=InternetClient gehen, das Protokollverhalten in Wireshark analysieren.³

Als Voraussetzung, was in einem Paket steht, zu lesen, hilft das Bild der Schichten Ethernet, IP, TCP und Anwendungsdaten. Die Anatomie der Schichten zeigt „Das OSI-Modell wirklich verstehen“.

3. pktmon in der Praxis — Filter, Start, Stopp, Wandlung

Die Grundlage des Mitschnitts sind die vier Schritte Filter registrieren → starten → stoppen → wandeln. Nach dem Ende räumen Sie auch den Filter auf. Das Folgende führen Sie in einer Konsole mit Administratorrechten aus.

Vor dem Start prüfen Sie bestehende Filter und die Aufräumung danach. Das letzte pktmon filter remove löscht nicht namentlich, sondern alle registrierten Filter. In einer Umgebung, die mit einer anderen Untersuchung geteilt wird, prüfen Sie zuerst mit pktmon filter list.

:: 1. Zuerst Filter registrieren und das Ziel einengen (TCP 8443 des Zielservers 192.168.10.20)
pktmon filter add App8443 -i 192.168.10.20 -t tcp -p 8443
pktmon filter list

:: 2. Mitschnitt starten. Das ganze Paket aufzeichnen, mit 1-GB-Ringpuffer überschreiben
pktmon start --capture --pkt-size 0 --file-name C:\temp\app-timeout.etl --file-size 1024 --log-mode circular

:: 3. Das Ereignis reproduzieren. Während des Wartens können Zähler Fluss und Verwurf zeigen
pktmon counters --drop-reason

:: 4. Stoppen und für Wireshark nach pcapng wandeln
pktmon stop
pktmon etl2pcap C:\temp\app-timeout.etl --out C:\temp\app-timeout.pcapng

:: 5. Registrierte Filter aufräumen (Filter bleiben, bis sie ausdrücklich gelöscht werden).
::    Hinweis: filter remove kann keinen Namen angeben und löscht „alle“ registrierten Filter.
::    Bleiben Filter einer anderen Untersuchung, zuerst mit pktmon filter list prüfen
pktmon filter remove

flowchart TB
    accTitle: Grundschritte von pktmon
    accDescr: Mit filter add das Ziel einengen, mit start --capture beginnen, das Ereignis reproduzieren, stoppen, mit etl2pcap nach pcapng wandeln, zuletzt den registrierten Filter löschen
    fa["1. Mit filter add das Ziel einengen"] --> st["2. Mit start --capture beginnen"]
    st --> re["3. Das Ereignis reproduzieren"]
    re -.-> ct["Mit counters Fluss und Verwurf prüfen"]
    re --> sp["4. Mit stop anhalten"]
    sp --> cv["Mit etl2pcap nach pcapng wandeln"]
    cv --> rm["5. Mit filter remove aufräumen"]

Abbildung 3: pktmon beginnt mit der Filterregistrierung und räumt nach Mitschnitt, Stopp und Wandlung den Filter ausdrücklich auf.

Bevor Sie die Befehle ausführen, verringern vier Festlegungen das erneute Aufnehmen.

Vor dem Mitschnitt prüfen

Das Ziel einengen: mehrere Filter sind ODER

Filter registrieren Sie vor dem Start. Auch Microsofts Dokumentation empfiehlt die Filteranwendung vor dem Start nachdrücklich, weil der Mitschnitt des gesamten Verkehrs zu viel Rauschen hat. Filter lassen sich nach IP-Adresse, Port, MAC-Adresse, Protokoll, VLAN-ID und mehr angeben, höchstens 32. Mehrere Filter sind die ODER-Bedingung „aufzeichnen, wenn eines zutrifft“.⁴

Die Richtung einengen: Quelle und Ziel werden nicht unterschieden

pktmon-Filter unterscheiden Quelle und Ziel nicht. -i 192.168.10.20 bedeutet „Pakete, in denen diese Adresse Quelle oder Ziel ist“. Die Richtung engen Sie nach der Wandlung mit einem Wireshark-Anzeigefilter ein.⁴

Den Aufzeichnungsbereich festlegen: nur Header oder das ganze Paket

Die Standardpaketgröße ist 128 Bytes. Für die Header-Analyse reicht das, zum Lesen der Anwendungsdaten zeichnen Sie mit --pkt-size 0 das Ganze auf.⁶

Die Kapazität festlegen: Ringpuffer und Echtzeitanzeige

Das Log ist standardmäßig im circular-Modus (Ringpuffer), die Standardgröße 512 MB. Mit --file-size ändern Sie die Obergrenze; --log-mode real-time zeigt auf dem Bildschirm in Echtzeit und erzeugt keine Logdatei. Prüfen Sie zuerst in der Echtzeitanzeige, dass der gewünschte Verkehr sichtbar ist, und legen Sie dann den Produktivmitschnitt, um ins Leere zu laufen zu vermeiden.⁶

flowchart TB
    accTitle: Wie pktmon-Filter wirken
    accDescr: Mehrere registrierte Filter wirken als ODER, die angegebene Adresse unterscheidet Quelle und Ziel nicht, die Richtung engen Sie nach der Wandlung mit einem Wireshark-Anzeigefilter ein
    f1["Filter 1"] --> orc["Aufzeichnen, wenn eines zutrifft"]
    f2["Filter 2"] --> orc
    f3["Filter 3 (höchstens 32)"] --> orc
    orc --> rec["Im Mitschnittlog aufgezeichnet (ODER)"]
    rec -.-> nodir["Quelle und Ziel werden nicht unterschieden"]
    nodir -.-> ws["Die Richtung nach der Wandlung in Wireshark einengen"]

Abbildung 4: Mehrere Filter wirken als ODER; ob Quelle oder Ziel, engen Sie nach der Wandlung in Wireshark ein.

3.1. Die eigene Stärke von pktmon — wo verworfen wurde

Der eigene Wert von pktmon gegenüber Wireshark ist, Pakete nicht an der einen Stelle der NIC, sondern an mehreren Stellen im Netzwerkstapel zu erfassen und Ort und Grund des Verwurfs (Drop) zu berichten. Sie sehen, bis zu welcher Komponente das Paket kam und wo es verschwand, und kommen von Drop-Gründen wie „MTU mismatch“ oder „VLAN-Filter“ zur Ursache, ohne alles durchzuprobieren.⁵

flowchart TB
    accTitle: pktmon erfasst an mehreren Stellen im Stapel
    accDescr: pktmon erfasst nicht an der einen Stelle der NIC, sondern an mehreren Stellen im Netzwerkstapel und berichtet mit Grund, bis zu welcher Komponente das Paket kam und wo es verworfen wurde
    pin["Paket"] --> p1["Erfassung an Stelle 1"]
    p1 --> p2["Erfassung an Stelle 2"]
    p2 --> p3["Verwurf an Stelle 3"]
    p3 -.-> rz["Verwurfstelle und Drop-Grund berichten"]
    rz -.-> ex["Beispiel MTU-Abweichung oder VLAN-Filter"]

Abbildung 5: Weil an mehreren Stellen im Stapel erfasst wird, sehen Sie mit Grund, wie weit es kam und wo es verworfen wurde.

Zuerst Zähler, bei Bedarf das Textlog prüfen

• Mit pktmon list sehen Sie Liste und ID der zu überwachenden Netzwerkkomponenten (NIC, Protokollstapel, Filtertreiber und mehr).
• Mit pktmon counters --drop-reason sehen Sie Durchgangs-/Verwurfszähler je Komponente und den jüngsten Drop-Grund. Das eignet sich als erste Eingrenzung vor der Loganalyse.¹¹
• Die Textwandlung mit pktmon etl2txt hängt an verworfenen Paketen drop und dropReason (Verwurfsgrund) an.⁴

Der Verdacht „irgendwo im OS vor der App verworfen“ lässt sich durch Betrachten von Wireshark allein nicht entscheiden. Bei der Eingrenzung eines Falls, in dem eine unzureichende Empfangsregel die Firewall droppt („Windows-Firewall und Business-Anwendungen“), wirkt diese Funktion.

Vor der Übergabe an Wireshark die Erfassungsstelle einengen

pktmon zeichnet dasselbe Paket an mehreren Stellen im Stapel auf. Wandeln Sie unverändert nach pcapng, kann dasselbe Paket doppelt erscheinen. pcapng übernimmt die Information „in welcher Komponente erfasst“ nicht.

Zum Lesen in Wireshark engen Sie die Stelle mit --component-id von pktmon etl2pcap ein. Es gibt auch die Methode, Drops allein mit --drop-only in eine andere Datei zu legen.¹

flowchart TB
    accTitle: Warum dieselbe Paket nach der pcapng-Wandlung doppelt erscheint
    accDescr: pktmon zeichnet dasselbe Paket an mehreren Stellen im Stapel auf; pcapng übernimmt nicht, in welcher Komponente erfasst wurde, deshalb erscheint es doppelt; Standard ist, mit component-id die Stelle einzuengen oder mit drop-only Drops in eine andere Datei zu legen
    same["Dasselbe Paket an mehreren Stellen aufzeichnen"] --> conv["Unverändert nach pcapng wandeln"]
    conv --> lost["Die Erfassungsstelle wird nicht übernommen"]
    lost --> dup["Dasselbe Paket erscheint doppelt"]
    dup --> c1["Mit --component-id die Stelle einengen"]
    dup --> c2["Mit --drop-only in eine andere Datei"]

Abbildung 6: Weil die Erfassungsstelle nicht nach pcapng übernommen wird, ist das Einengen der Stelle vor der Wandlung der Standard.

4. netsh trace in der Praxis — Szenario, ETL, Mitschnitt über Neustart

netsh trace ist der Tracemitschnitt, der länger als pktmon in Windows liegt. Das Merkmal ist, als „Szenario“ die zum Problem gehörenden ETW-Provider gebündelt zu aktivieren.⁸

:: Liste nutzbarer Szenarien und die Provider im Szenario prüfen
netsh trace show scenarios
netsh trace show scenario netconnection

:: Mitschnitt starten. Mit Paketmitschnitt, 1-GB-Ringpuffer
netsh trace start scenario=netconnection capture=yes tracefile=C:\temp\nettrace.etl maxSize=1024 filemode=circular

:: Das Ereignis reproduzieren, dann stoppen (das Mergen braucht etwas Zeit)
netsh trace stop

Aufnahmebedingungen, die Sie bei netsh trace festlegen

Sollen auch Pakete bleiben, capture=yes anhängen

Mit capture=yes ist Paketmitschnitt aktiv, und Sie engen mit Capture-Filtern wie ipv4.address=192.168.10.20 ein. Die Filterliste sehen Sie mit netsh trace show capturefilterHelp.⁸

Zusammen mit ETL bleibt Umgebungsinformation in der .cab

Beim Stopp entsteht neben der ETL-Datei eine .cab. Die .cab enthält Systeminformationen wie Adapterkonfiguration und OS-Build und kann die Sammlung der Umgebung mitübernehmen.⁸

Vor dem Start bestehende Sitzungen prüfen

Es kann nur eine Tracesitzung gleichzeitig laufen. Bevor Sie einen anderen Mitschnitt beginnen, prüfen Sie mit netsh trace show status, ob eine Sitzung weiterläuft.⁸

Für Ereignisse unmittelbar nach dem Neustart persistent=yes nutzen

Mit persistent=yes bleibt die Sitzung über einen Neustart. Mitschnitte von Ereignissen, bei denen der manuelle Start nicht rechtzeitig kommt — „unmittelbar nach dem Neustart scheitert die Kommunikation einen Moment“ oder „die Dienstverbindung beim Start scheitert“ — sind die Stärke von netsh trace.⁷

flowchart TB
    accTitle: Szenariomitschnitt von netsh trace
    accDescr: Mit Angabe eines Szenarios starten, ETW-Provider gebündelt aktivieren; mit capture=yes auch Pakete; beim Stopp entstehen ETL-Datei und .cab
    sc["Mit Szenario starten"] --> pv["Provider gebündelt aktivieren"]
    sc -->|capture=yes| pc["Auch Pakete aufnehmen"]
    pv --> re["Das Ereignis reproduzieren"]
    pc --> re
    re --> sp["Mit stop anhalten"]
    sp --> etl["ETL-Datei"]
    sp --> cab[".cab (Systeminformationen)"]

Abbildung 7: Mit einem Szenario werden Provider gebündelt aktiviert; beim Stopp entstehen ETL und .cab.

4.1. ETL in eine für Wireshark lesbare Form bringen — etl2pcapng

Die ETL von netsh trace öffnet Wireshark nicht unverändert. Mit dem Open-Source-Werkzeug etl2pcapng, das Microsoft auf GitHub veröffentlicht, wandeln Sie Pakete in einer mit netsh trace start capture=yes aufgenommenen ETL nach pcapng.²

etl2pcapng.exe C:\temp\nettrace.etl C:\temp\nettrace.pcapng

etl2pcapng schreibt bei der Wandlung die beteiligte Prozess-ID als Paketkommentar. „Kommunikation welches Prozesses“ sehen Sie in Wireshark, das hilft bei der Eingrenzung in einer Umgebung, in der mehrere Apps auf demselben Server kommunizieren.²

Pakete und interne Windows-Ereignisse lesen Sie verschieden

Die ETW-Ereignisse (interne Windows-Ereignisse, die Szenarioprovider aufzeichnen) werden nicht nach pcapng gewandelt. Wollen Sie auch Ereignisse lesen, wandeln Sie mit netsh trace convert input=C:\temp\nettrace.etl in Text oder öffnen in Windows Performance Analyzer.⁷³

flowchart TB
    accTitle: Das Lesen der ETL von netsh trace teilt sich in zwei Wege
    accDescr: Pakete in der ETL wandelt etl2pcapng nach pcapng zum Lesen in Wireshark; ETW-Ereignisse gehen nicht nach pcapng und lesen Sie mit netsh trace convert oder Windows Performance Analyzer
    etl["ETL von netsh trace"] --> pk["Pakete"]
    etl --> ev["ETW-Ereignisse"]
    pk -->|etl2pcapng| pc["Nach pcapng wandeln"]
    pc --> ws["In Wireshark lesen"]
    pc -.-> pid["Prozess-ID bleibt im Kommentar"]
    ev -.-> no["Wird nicht nach pcapng gewandelt"]
    no --> alt["Mit convert oder WPA lesen"]

Abbildung 8: Pakete der ETL wandeln Sie nach pcapng; ETW-Ereignisse lesen Sie auf einem anderen Weg.

5. Einführung ins Lesen in Wireshark — Anzeigefilter und TCP-Analyse

Die Analyse geht in der Reihenfolge das Ziel einengen → die TCP-Form prüfen → bei Bedarf die ganze Unterhaltung sehen. Öffnen Sie zuerst die pcapng und schneiden Sie Rauschen mit einem Anzeigefilter.¹²¹³

Mit dem Anzeigefilter das Leseziel einengen

tcp.analysis.* sind Analyseflags, mit denen Wireshark TCP-Sequenznummern verfolgt und automatisch urteilt. Neuübertragung, doppeltes ACK, Vertauschung der Reihenfolge, ZeroWindow und mehr werden mechanisch gefunden, deshalb ist zuerst tcp.analysis.flags zu setzen und „problemverdächtige Stellen“ aufzulisten der Standard zum Lesebeginn.¹³

Timeout in vier Prüfpunkte teilen

Haben Sie mit tcp.analysis.flags getroffen, prüfen Sie in dieser Reihenfolge. Besonders Neuübertragung ist die Beobachtung „ACK kommt nicht zurück“; mit nur einer Seite entscheiden Sie nicht, ob Hin- oder Rückweg verloren ging.

1. Kam die Verbindung zustande: SYN, SYN/ACK, ACK

Kam der Drei-Wege-Handshake zustande? Sind die drei SYN → SYN/ACK → ACK vollständig? Wiederholtes SYN ohne Antwort bedeutet, dass es den Partner nicht erreichte oder unterwegs still verworfen wurde (typisches Firewall-Muster).

2. Wurde erzwungen getrennt: Zeitpunkt und Quelle von RST

Von welcher Seite kam RST? RST sofort auf SYN bedeutet, dass am Zielport niemand lauscht; RST nach dem Herstellen bedeutet, dass eine Seite die Verbindung erzwungen trennte. Die Quell-IP von RST ist der direkte Beleg, „wer trennte“.

3. Kommt ACK zurück: Fortsetzung der Neuübertragung

Geht die Neuübertragung weiter? Wiederholte Neuübertragung desselben Segments ist das Zeichen, dass die Bestätigung (ACK) nicht zur Sendeseite zurückkommt. Ob die Hin-Daten oder das Rück-ACK verloren gingen, kann ein einseitiger Mitschnitt nicht festmachen (deshalb wirkt „auf beiden Seiten aufnehmen“ im nächsten Kapitel). Die Vertiefung von Neuübertragung und Timeout behandelt „TCP-Retransmission als Ursache für Kommunikationsausfälle bei Industriekameras“.

4. Ist die Empfangsseite voll: ZeroWindow

Erscheint ZeroWindow? Das ist das Zeichen, dass die Empfangs-App nicht aus dem Socket liest und der Empfangspuffer voll ist. Es wird zum Beleg, nicht das Netz, sondern den Entwurf der Empfangs-App zu verdächtigen („Der Irrglaube, man könne über TCP pro Send genau eine Einheit empfangen“).

flowchart TB
    accTitle: Reihenfolge der Formen, die eine Timeout-Untersuchung sucht
    accDescr: Drei-Wege-Handshake, Vorhandensein und Quelle von RST, Fortsetzung der Neuübertragung, ZeroWindow der Reihe nach prüfen und die Ursache treffen
    hs{"Antwort auf SYN?"} -->|nein| ng["Verdacht auf Verwurf ohne Ankunft (typisch FW)"]
    hs -->|ja| rs{"Fliegt RST?"}
    rs -->|ja| who["Die RST-Quelle ist die trennende Seite"]
    rs -->|nein| rt{"Geht die Neuübertragung weiter?"}
    rt -->|ja| ack["Zeichen, dass ACK nicht zurückkommt"]
    rt -->|nein| zw{"Erscheint ZeroWindow?"}
    zw -->|ja| app["Zeichen, dass die Empfangs-App nicht liest"]

Abbildung 9: Handshake, RST, Neuübertragung, ZeroWindow der Reihe nach zu suchen, grenzt den nächsten Untersuchungsort ein.

Bei viel Verkehr zuerst mit Statistik überblicken, dann lesen

Bevor Sie Paket für Paket lesen, ist es wirksam, mit Statistik die Zielunterhaltung und das Zeitfenster zu suchen.

flowchart TB
    accTitle: Mit Statistik überblicken, dann die Unterhaltung einengen
    accDescr: Mit Conversations auflisten, welche Kommunikation wann wie viel sprach, die Zielunterhaltung festmachen, mit I/O Graph das stumme Zeitfenster greifen, nur die Zielunterhaltung filtern und den TCP-Stream durchlesen
    ov["Mit Statistik das Ganze überblicken"] --> cv["Unterhaltungsliste in Conversations"]
    ov --> io["Fluss im E/A-Graph sehen"]
    cv --> flt["Nur die Zielunterhaltung filtern"]
    io -.-> mute["Die stumme Zeit wird sichtbar"]
    flt --> fs["TCP-Stream durchlesen"]

Abbildung 10: Bevor Sie Paket für Paket lesen, überblicken Sie mit Statistik und engen auf die Zielunterhaltung ein.

6. Die Loopback-Falle — Ziele an localhost gehen nicht durch die NIC

Die Kommunikation zwischen Apps auf demselben PC — etwa die Verbindung der Geschäftsanwendung zum Zwischendienst localhost:8080 — zu untersuchen und an „in Wireshark erscheint nichts“ hängen zu bleiben, ist die klassische Falle.

Die Ursache ist klar. Verkehr zu localhost (127.0.0.1) geht nicht durch eine physische NIC und wird auf dem internen Loopback-Pfad des OS umgedreht. In einem gewöhnlichen Mitschnitt, der einen physischen Adapter anvisiert, erscheint er von Anfang an nicht.⁹

flowchart TB
    accTitle: Warum Verkehr zu localhost nicht im Mitschnitt erscheint
    accDescr: Verkehr zu localhost geht nicht durch eine physische NIC und wird intern umgedreht, deshalb erscheint er in einem gewöhnlichen Mitschnitt eines physischen Adapters nicht
    app["App"] --> stack["Netzwerkstapel"]
    stack -->|externes Ziel| nic["physische NIC"]
    nic --> seen["Erscheint im gewöhnlichen Mitschnitt"]
    stack -->|Ziel localhost| lo["Internes Umdrehen im OS"]
    lo -.-> miss["Erscheint nicht im gewöhnlichen Mitschnitt"]
    lo -.-> alt["Mit Npcap-Loopback oder pktmon aufnehmen"]

Abbildung 11: Ziele an localhost werden vor der NIC umgedreht und erscheinen von Anfang an nicht im Mitschnitt eines physischen Adapters.

Das Aufnahmeverfahren dem Loopback-Pfad anpassen

Die Abhilfe ist zweifach.

• Mitschnitt in Wireshark: Wählen Sie Npcaps „Adapter for loopback traffic capture“ als Mitschnittziel. Der Windows-Installer von Wireshark (3.0 und später) enthält Npcap, in einer Umgebung mit Wireshark brauchen Sie keine Zusatzarbeit.⁹
• Mitschnitt mit dem Standardwerkzeug: pktmon nimmt nicht außerhalb der NIC, sondern an mehreren Stellen im Netzwerkstapel auf⁵ und eignet sich auch zur Beobachtung von Loopback. Zur Sicherheit prüfen Sie vor dem Warten auf die Produktivreproduktion in der Echtzeitanzeige pktmon start -c -m real-time in dieser Umgebung, dass der gewünschte Loopback-Verkehr wirklich sichtbar ist.

Auch bei der Adressangabe gibt es zwei Verwechslungen

localhost meint nicht unbedingt 127.0.0.1

„localhost“ kann nach IPv6 ::1 aufgelöst werden. Die App verbindet nach ::1 (IPv6), die Untersuchungsseite sieht nur 127.0.0.1 (IPv4) und urteilt falsch „keine Kommunikation“. Setzen Sie den Anzeigefilter auf beide, etwa ip.addr == 127.0.0.1 || ipv6.addr == ::1, oder geben Sie das Verbindungsziel der App als Adresse an.⁹

Die eigene reale IP anzugeben heißt nicht, durch die physische NIC zu gehen

Auch Verkehr zur eigenen realen IP erscheint nicht auf der Leitung. Verbindet dieselbe PC von 192.168.10.5 nach 192.168.10.5, wird intern umgedreht, auch wenn das Ziel eine reale IP ist. Merken Sie: „reale IP angegeben, also durch die NIC“ gilt nicht unbedingt.

flowchart TB
    accTitle: Die Verwechslung, dass localhost nach IPv6 aufgelöst wird
    accDescr: Das localhost der App kann nach ::1 (IPv6) aufgelöst sein; sieht die Untersuchungsseite nur 127.0.0.1, urteilt sie falsch, es gebe keine Kommunikation; Filter auf beide Adressen setzen oder das Ziel als Adresse angeben
    app["Die App verbindet nach localhost"] --> v6["Tatsächlich nach ::1 (IPv6) aufgelöst"]
    look["Die Untersuchungsseite sieht nur 127.0.0.1"] --> none["Auf dem Bildschirm erscheint nichts"]
    v6 --> none
    none --> fix1["Filter auf beide Adressen"]
    none --> fix2["Das Ziel als Adresse angeben"]

Abbildung 12: Achten Sie auf die Verwechslung, localhost nach ::1 aufzulösen und bei nur 127.0.0.1 „keine Kommunikation“ zu urteilen.

7. Wo aufnehmen — eine Seite, beide Seiten, Zeitsynchronisation

Was eine Seite liefert, sind die Fakten, die von diesem Aufnahmepunkt sichtbar waren. Ob Sie zuerst das Gesamtbild sehen oder bis dahin gehen wollen, ob Hin- oder Rückweg die Kommunikation verschwinden ließ, bestimmt den Aufnahmeort.

Auch wenn auf der Clientseite die Neuübertragung weitergeht, unterscheidet eine Seite die folgenden zwei nicht.

• Das gesendete Paket verschwand, bevor es den Server erreichte.
• Das Paket erreichte den Server, die Antwort verschwand auf dem Rückweg.

Nehmen Sie auf beiden Seiten auf und gleichen ab, steht fest, etwa „der Client sandte, der Server empfing nicht“, welche Seite schwieg. Wollen Sie die Verantwortungsgrenze (App, OS, Netzgerät, Gegenseite) festmachen, planen Sie von Anfang an den beidseitigen Mitschnitt.

flowchart TB
    accTitle: Was einseitiger und beidseitiger Mitschnitt zeigen
    accDescr: Ein einseitiger Mitschnitt unterscheidet nicht, ob das Hin-Paket oder die Rück-Antwort verschwand; der Abgleich beider Seiten macht fest, welche Seite schwieg
    one["Nur eine Seite aufnehmen"] --> fact["Nur die Fakten von der eigenen Position"]
    fact --> und["Hin verschwunden oder Rück verschwunden, ununterscheidbar"]
    both["Beide Seiten gleichzeitig aufnehmen"] --> mt["Abgleichen"]
    mt --> fix["Welche Seite schwieg, steht fest"]
    mt -.-> pre["Voraussetzung ist die Zeitsynchronisation beider Maschinen"]

Abbildung 13: Eine Seite zeigt nur sichtbare Fakten; erst der Abgleich beider Seiten macht die Verantwortungsgrenze fest.

7.1. Voraussetzung des Abgleichs ist Zeitsynchronisation

Um Mitschnitte beider Seiten abzugleichen, müssen die Uhren beider Maschinen übereinstimmen. Vor dem Mitschnitt prüfen und zeichnen Sie die Zeitabweichung auf.

:: Zustand der Zeitsynchronisation (Synchronisationsziel, letzte Synchronisationszeit) prüfen
w32tm /query /status

:: Die Zeitdifferenz zum Partnerserver messen (5 Proben)
w32tm /stripchart /computer:sv-app01 /dataonly /samples:5

w32tm /stripchart zeigt den Zeitversatz zwischen Ihnen und dem Partnerrechner und wird zum Beleg, beim Abgleich „die Serverseite war +0,8 s versetzt“ zu korrigieren.¹⁴ In einer Umgebung mit großer Abweichung ist es am Ende der kürzere Weg, zuerst die Zeitsynchronisation zu richten und dann aufzunehmen.

flowchart TB
    accTitle: Schritte zur Prüfung der Zeitdifferenz vor dem Abgleich
    accDescr: Mit w32tm den eigenen Synchronisationszustand prüfen, mit stripchart die Zeitdifferenz zum Partnerserver messen und aufzeichnen, beim Abgleich als Korrekturbeleg nutzen; bei großer Abweichung zuerst die Synchronisation richten, dann aufnehmen
    st["Mit query den Synchronisationszustand prüfen"] --> mc["Mit stripchart die Zeitdifferenz messen"]
    mc --> rc["Die Abweichung aufzeichnen"]
    rc --> use["Beim Abgleich als Korrekturbeleg"]
    mc -.-> big["Bei großer Abweichung zuerst die Synchronisation richten"]

Abbildung 14: Messen und zeichnen Sie die Zeitdifferenz vor dem Mitschnitt auf und nutzen Sie sie als Korrekturbeleg beim Abgleich.

7.2. Bei „unklar, wann es auftritt“ der Ringpuffer

Bei Ereignissen ohne klare Reproduktionsbedingung ist die Grundlage, mit Ringpuffer durchlaufen zu lassen und beim Auftreten zu stoppen.

• pktmon: Der Standard ist circular. Mit --file-size geben Sie die Obergrenze (MB) an, alte Pakete werden überschrieben.⁶
• netsh trace: Geben Sie etwa maxSize=1024 filemode=circular an.⁷
• Wireshark: Unter [Mitschnitt]→[Optionen]→[Ausgabe] können Sie „mehrere Dateien + Ringpuffer“ konfigurieren. Bei Umschalten nach Dateigröße oder Zeit bleiben nur die neuesten N, so läuft es lange mit Obergrenze des Plattenverbrauchs.¹⁵

Nicht nur die Kapazität, auch das Stoppen nach dem Auftreten festlegen

In jedem Fall teilen Sie mit der verantwortlichen Person vor Ort den Betrieb, beim Auftreten „zuerst die Auftretenszeit zu notieren und dann“ den Mitschnitt zu stoppen. Je länger der Ringpuffer wartet, desto mehr Vergangenheit verschwindet; ist der Weg von Auftreten bis Stopp lang, wird der entscheidende Abschnitt überschrieben.

flowchart TB
    accTitle: Warten mit Ringpuffer
    accDescr: Bei unklarer Reproduktion mit Ringpuffer durchlaufen lassen, beim Auftreten die Zeit notieren und zügig stoppen; spätes Stoppen überschreibt von alten Paketen und der entscheidende Abschnitt verschwindet
    st["Mitschnitt mit Ringpuffer starten"] --> wt["Durchlaufen lassen und warten"]
    wt --> ev["Das Ereignis tritt auf"]
    ev --> memo["Auftretenszeit notieren"]
    memo --> sp["Zügig stoppen"]
    wt -.-> ow["Von alten Paketen überschreiben"]
    ow -.-> late["Spätes Stoppen lässt den entscheidenden Abschnitt verschwinden"]

Abbildung 15: Je länger der Ringpuffer wartet, desto mehr Vergangenheit verschwindet; nach Notieren der Auftretenszeit zügig stoppen.

8. Das Problem, dass TLS den Inhalt verbirgt — was trotzdem sichtbar bleibt

Vor dem Entschlüsseln das Skelett der Kommunikation prüfen

Ein großer Teil der heutigen Geschäftskommunikation ist TLS (HTTPS). Man denkt gern „verschlüsselt, also ist Mitschnitt zwecklos“, aber das meiste, was eine Timeout-Untersuchung wissen will, bleibt auch verschlüsselt sichtbar.

• Ob die TCP-Verbindung zustande kam (Drei-Wege-Handshake)
• Wie weit der TLS-Handshake kam — ob auf ClientHello ServerHello zurückkam, ob mitten im Handshake RST oder Alert schnitt
• Der Zielhostname (SNI) in ClientHello und die ausgehandelte TLS-Version
• Nach dem Herstellen, welche Seite das Senden einstellte. Lage der Nichtantwort, Neuübertragung, RST oder normales Schließen (FIN)

Die Eingrenzung von „verbindet nicht“, „bricht unterwegs ab“, „Antwort kommt nicht“ braucht also fast keine Entschlüsselung des Inhalts. Was die Verschlüsselung nimmt, ist „worüber gesprochen wurde“, „wer wann schwieg“ bleibt.

flowchart TB
    accTitle: Was ein TLS-Mitschnitt zeigt und was nicht
    accDescr: Verschlüsselung verbirgt nur den Inhalt der Anwendungsdaten; TCP-Aufbau, Erfolg des TLS-Handshake, SNI und TLS-Version, RST und welche Seite schwieg bleiben auch verschlüsselt sichtbar
    tls["Mitschnitt von TLS-Verkehr"] --> vis["Sichtbar"]
    tls --> hid["Nicht sichtbar"]
    vis --> v1["TCP-Verbindungsaufbau"]
    vis --> v2["TLS-Erfolg und SNI"]
    vis --> v3["RST und welche Seite schwieg"]
    hid --> h1["Inhalt der Anwendungsdaten"]

Abbildung 16: Die Verschlüsselung nimmt nur den Inhalt; das Skelett der Kommunikation bleibt auch unter TLS lesbar.

Nur wenn der Inhalt nötig ist, die Entschlüsselbarkeit prüfen

Ist der Inhalt trotzdem nötig, hat Wireshark den Mechanismus, TLS mit dem über die Umgebungsvariable SSLKEYLOGFILE geschriebenen Sitzungsschlüssel zu entschlüsseln. Unterstützt sind jedoch nur einige Implementierungen wie Firefox, Chrome, Chromium-Edge und OpenSSL-Bibliotheken; das Windows-Standard-SChannel (Apps, die WinHTTP oder WinINET nutzen) unterstützt diesen Mechanismus nicht.¹⁰ Weil der Sitzungsschlüssel in eine Datei geschrieben wird — wer die Datei hat, kann die ganze Kommunikation entschlüsseln — sollten Sie ihn nicht als Mittel der Produktivumgebung, sondern zur Reproduktion und Fehlersuche in der Entwicklung einordnen.

flowchart TB
    accTitle: Mechanismus und Grenzen der Entschlüsselung über SSLKEYLOGFILE
    accDescr: Mit dem über SSLKEYLOGFILE geschriebenen Sitzungsschlüssel kann Wireshark TLS entschlüsseln; unterstützt sind nur einige Implementierungen wie Firefox und Chrome, SChannel nicht; wer die Schlüsseldatei hat, kann entschlüsseln, deshalb nur Entwicklungsumgebung
    env["SSLKEYLOGFILE setzen"] --> key["Sitzungsschlüssel in eine Datei schreiben"]
    key --> ws["In Wireshark entschlüsselt lesen"]
    key -.-> risk["Wer den Schlüssel hat, entschlüsselt alles"]
    risk -.-> dev["Als Entwicklungsumgebung einordnen"]
    env -.-> sup["Nur einige TLS-Implementierungen"]
    sup -.-> sch["SChannel nicht unterstützt"]

Abbildung 17: Schreiben des Sitzungsschlüssels ermöglicht Entschlüsselung, die unterstützten Implementierungen sind begrenzt, wegen der Schlüsseleigenschaft nur Entwicklungsumgebung.

Bei Kommunikation über einen Unternehmensproxy wird das im Mitschnitt sichtbare Ziel der Proxyserver, und TLS fließt im CONNECT-Tunnel. Das vorgelagerte Problem, zu welchem Proxy die App überhaupt geht, ordnet der am selben Tag erschienene Schwesterartikel „Unternehmensproxy und Windows-Apps — Proxyauflösung in WinINET, WinHTTP und .NET“.

9. Abgleich mit dem Anwendungslog — Zeiten auf dieselbe Achse legen

Ein Mitschnitt allein führt selten zum Schluss. Der praktische Hebel ist, eine Logzeile und einen Paket-Hin-und-Rück auf dieselbe Zeitachse zu legen.

Eine Logzeile durch eine Paketbeobachtung ersetzen

Zuerst suchen Sie aus der Ausnahmezeit den Abschnitt, in dem die Kommunikation begann.

Schritt 1: Aus Ausnahmezeit und Timeoutwert die Startzeit suchen

Bestimmen Sie die Ereigniszeit aus dem Anwendungslog (Beispiel: Timeout-Ausnahme um 10:23:41). Bei Timeoutwert 30 Sekunden sollte der Start um 10:23:11 liegen.

Schritt 2: Wireshark auf Datum/Uhrzeit stellen und den Abschnitt einengen

Schalten Sie die Zeitanzeige von Wireshark unter [Ansicht]→[Zeitdarstellung]→[Datum und Uhrzeit] und engen Sie den Abschnitt mit einem Anzeigefilter ein (auch nach Zeit, etwa frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00").

Schritt 3: Handshake, RST, Neuübertragung, ZeroWindow prüfen

In diesem Abschnitt prüfen Sie die Reihenfolge aus Kapitel 5 (Handshake → RST → Neuübertragung → ZeroWindow). Können Sie bis „30 Sekunden vor der Timeout-Zeit des Logs SYN gesendet, danach nur SYN-Neuübertragung“ abgleichen, wird das Timeout des Logs zur Beobachtung „an diesem Aufnahmepunkt kam überhaupt keine Antwort“ (ob SYN den Partner nicht erreichte oder das Rück-SYN/ACK auf dem Rückweg verloren ging, macht dieser Aufnahmepunkt allein nicht fest. Zum Festmachen gleichen Sie mit dem Mitschnitt der Serverseite ab).

Schritt 4: Zeitdifferenz und Zeitzone korrigieren

Korrigieren Sie unbedingt die Abweichung zwischen Mitschnittzeit und Logzeit (in 7.1 gemessene Zeitdifferenz, Zeitzonenangabe des Logs). Ein Abgleichfehler von wenigen Sekunden macht eine andere Kommunikation zum Täter.

flowchart TB
    accTitle: Schritte zum Abgleich von Anwendungslog und Paketen
    accDescr: Ereigniszeit aus dem Anwendungslog, Startzeit aus dem Timeoutwert rückrechnen, in Wireshark den Abschnitt einengen, die Form der Reihe nach prüfen, die Zeitabweichung korrigieren und auf dieselbe Zeitachse legen
    lg["1. Ereigniszeit im Log festmachen"] --> rev["Start aus dem Timeoutwert rückrechnen"]
    rev --> flt["2. Den Abschnitt mit Anzeigefilter einengen"]
    flt --> chk["3. Die Form in der Reihenfolge von Kapitel 5 prüfen"]
    chk --> adj["4. Die Zeitabweichung korrigieren"]
    adj --> done["Das eine Logwort wird zur Beobachtung"]

Abbildung 18: Aus der Logzeit den Abschnitt einengen, die Form prüfen, die Zeitdifferenz korrigieren und auf dieselbe Achse legen.

Vor der Übergabe an Dritte nur die nötige Unterhaltung herausnehmen

Wenn Sie das Untersuchungsergebnis an Dritte (Anbieter, Leitungsbetreiber, Netzverantwortliche des Kunden) übergeben, ist nach dem Schneiden von Rauschen mit dem Filter zu übergeben Höflichkeit und Sicherheit. Engen Sie in Wireshark nur die Zielunterhaltung mit einem Anzeigefilter ein und speichern Sie unter [Datei]→[Angegebene Pakete exportieren] „nur angezeigte Pakete“, entsteht eine kleine pcapng nur des nötigen Bereichs.

Schon vor dem Mitschnitt Aufbewahrung und Löschung vertraulicher Daten festlegen

Die Mitschnittdatei enthält die Kommunikation selbst. Klartext-Anmeldedaten, HTTP-Cookies und API-Schlüssel, Inhalt von Mail und Belegen, personenbezogene Daten können enthalten sein. Legen Sie die folgenden drei Punkte zusammen mit dem Aufnahmeverfahren fest.

• Minimal nötiger Mitschnitt: Mit Filtern vor dem Mitschnitt (Kapitel 3 und 4) das Ziel einengen, auch den Zeitraum minimal. „Erst einmal alles“ in der Kundenumgebung nicht tun
• Einengen vor der Übergabe: Nur die Zielunterhaltung exportieren, irrelevante Kommunikation Dritter nicht einschließen. Bleiben vertrauliche Teile, vereinbaren Sie Maskierung oder einen anderen Weg mit dem Empfänger
• Aufbewahrung und Löschung: Ort, Frist und Löschung der Mitschnittdatei festlegen und nach Abschluss der Untersuchung löschen

flowchart TB
    accTitle: Drei Festlegungen vor der Übergabe einer Mitschnittdatei
    accDescr: Der Mitschnitt enthält die Kommunikation selbst; vor dem Mitschnitt mit Filter und Zeitraum auf das Minimum einengen, vor der Übergabe nur die Zielunterhaltung extrahieren, Aufbewahrungsort und Frist festlegen und nach der Untersuchung löschen
    cap["Der Mitschnitt enthält die Kommunikation"] --> p1["Der Mitschnitt auf das Minimum"]
    cap --> p2["Vor der Übergabe nur das Ziel extrahieren"]
    cap --> p3["Aufbewahrungsfrist festlegen und löschen"]
    p2 -.-> exp["Mit Anzeigefilter einengen und exportieren"]

Abbildung 19: Minimaler Mitschnitt, Einengen vor der Übergabe, Aufbewahrung und Löschung als Satz mit dem Aufnahmeverfahren festlegen.

10. Zusammenfassung

• Eine Schicht unter dem Timeout des Anwendungslogs liegt die Tatsache der Pakete, die wirklich über die Leitung gingen. Ob SYN keine Antwort bekam, RST schnitt, die Neuübertragung weiterging oder ZeroWindow erschien, ändert den nächsten Untersuchungsort.
• Auch ohne Wireshark vor Ort nehmen die Windows-Standardwerkzeuge pktmon und netsh trace auf. Mit dem Standardwerkzeug aufnehmen, in Wireshark auf dem eigenen Rechner lesen ist das Grundmuster.
• pktmon in vier Schritten: Filter registrieren → pktmon start --capture → pktmon stop → pktmon etl2pcap. Standardmäßig auf 128 Bytes gekürzt, zum Lesen des Inhalts --pkt-size 0 nicht vergessen. Verwurfstelle und Grund zu sehen ist die Stärke nur von pktmon.
• netsh trace bündelt ETW-Provider als Szenario und geht mit persistent=yes über den Neustart. ETL lesen Sie nach Wandlung mit etl2pcapng nach pcapng.
• In Wireshark beginnen Sie mit tcp.analysis.flags und suchen Handshake, RST, Neuübertragung, ZeroWindow der Reihe nach. Mit Conversations und I/O Graph überblicken und dann einengen ist schneller.
• Ziele an localhost gehen nicht durch die NIC und sind gewöhnlich nicht aufzunehmen. Nutzen Sie den Loopback-Adapter von Npcap oder die Aufnahme von pktmon im Stapel.
• Der Abgleich beider Seiten macht fest, welche Seite schwieg. Die Voraussetzung ist Zeitsynchronisation (w32tm). Ereignisse ohne Reproduktionsbedingung erwarten Sie mit Ringpuffer.
• Auch unter TLS bleibt das Skelett der Kommunikation sichtbar. Entschlüsselung (SSLKEYLOGFILE) als Mittel nur der Entwicklung einordnen und die Mitschnittdatei selbst als vertraulich mit minimalem Mitschnitt, Einengen und Löschen in den Betrieb nehmen.

Paketmitschnitt gilt gern als „Werkzeug der Netzfachleute“, ist in der Praxis jedoch ein Untersuchungswerkzeug auf der App-Seite, das erst im Abgleich mit dem Anwendungslog Sinn ergibt. Wenn das nächste Mal die Untersuchung beim einen Wort Timeout stehen bleibt, gehen Sie eine Schicht tiefer.

Verwandte Artikel

• TCP-Retransmission als Ursache für Kommunikationsausfälle bei Industriekameras – Ursachensuche und Eingrenzung
• Der Irrglaube, man könne über TCP pro Send genau eine Einheit empfangen ── Empfangslogik entwerfen, die es als Bytestrom behandelt
• Das OSI-Modell wirklich verstehen — eine einzelne HTTP-Anfrage in ihre sieben Schichten zerlegen
• Process Monitor (ProcMon) Praxisleitfaden — „Konfiguration wird nicht gelesen“ und ACCESS DENIED in 10 Minuten identifizieren
• Windows-Firewall und Business-Anwendungen — Eingehende Regeln über das Installationsprogramm registrieren
• Unternehmensproxy und Windows-Apps — Proxyauflösung in WinINET, WinHTTP und .NET

Verwandte Beratungsbereiche

Die KomuraSoft LLC übernimmt kommunikationsgetriebene Fehleruntersuchungen wie „die Kommunikation der Geschäftsanwendung scheitert gelegentlich, die Ursache ist unklar“ und „nur in der Kundenumgebung auftretende Verbindungsfehler eingrenzen“. Vom Entwurf des Paketmitschnitts (wo, was, wie viel) über die Analyse in Wireshark, den Abgleich mit dem Anwendungslog bis zur Korrektur auf der App-Seite als einen Zusammenhang.

• Windows-App-Entwicklung
• Fehleruntersuchung und Ursachenanalyse
• Technische Beratung und Design-Review
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wie fange ich Pakete auf einem Kundenserver, auf dem ich Wireshark nicht installieren darf?

Nutzen Sie die mitgelieferten Windows-Werkzeuge pktmon oder netsh trace — zusätzliche Software ist nicht nötig. Bei pktmon registrieren Sie in einer privilegierten Konsole einen Filter, starten den Mitschnitt mit pktmon start --capture und beenden ihn mit pktmon stop. Die entstandene ETL-Datei lässt sich mit pktmon etl2pcap nach pcapng wandeln, die Analyse holen Sie sich in Wireshark auf dem eigenen Rechner. Mit dem Inbox-Werkzeug mitschneiden, mit Wireshark lesen ist die Grundaufteilung auf Installations-gesperrten Standorten.

Soll ich pktmon oder netsh trace verwenden?

Hat das Betriebssystem pktmon (Windows 10 / Windows Server 2019 und später), beginnen Sie mit pktmon. Die Befehle sind einfach, Sie sehen, welche Komponente des Netzwerkstapels das Paket verworfen hat (der Drop-Grund), und die pcapng-Wandlung ist in sich geschlossen. netsh trace ist die bessere Wahl, wenn Sie auf einem älteren OS ohne pktmon mitschneiden, wenn Sie ETW-Ereignisse von Windows-Komponenten als Szenario sammeln wollen oder wenn der Mitschnitt mit persistent=yes einen Neustart überleben soll. Auch Microsofts eigene Fehlersuche-Materialien zeigen diese Reihenfolge: zuerst pktmon, dann netsh trace, wenn das nicht reicht.

Warum erscheint Verkehr zu localhost (127.0.0.1) nicht in Wireshark?

Verkehr zu localhost geht nie durch eine physische NIC; er wird auf dem internen Loopback-Pfad des Betriebssystems umgedreht. Ein normaler Mitschnitt, der einen physischen Adapter anvisiert, sieht ihn daher nie. In Wireshark wählen Sie Npcaps Adapter for loopback traffic capture und können Loopback-Verkehr mitschneiden. pktmon schneidet innerhalb des Netzwerkstapels mit und kann Loopback-Verkehr ebenfalls beobachten. Eine weitere häufige Verwechslung: localhost löst nach IPv6 ::1 auf, ein Bildschirm, der auf 127.0.0.1 wartet, zeigt nichts — bestätigen Sie, indem Sie die Adresse ausdrücklich angeben.

Kann ich den Inhalt von HTTPS-(TLS-)Verkehr in einem Paketmitschnitt sehen?

Die Nutzlast der Anwendungsdaten ist verschlüsselt und nicht sichtbar. Das Skelett der Unterhaltung — TCP-Auf- und -Abbau, ob der TLS-Handshake gelang, ein RST-Abbruch, welche Seite nicht mehr antwortete — bleibt auch verschlüsselt sichtbar, die meisten Timeout-Untersuchungen kommen mit unentschlüsseltem TLS aus. Brauchen Sie die Nutzlast, gibt es die Entschlüsselung über SSLKEYLOGFILE, aber nur einige TLS-Implementierungen wie Firefox und die Chrome-Familie unterstützen sie; das inbox-SChannel von Windows nicht. Der Mechanismus schreibt Schlüsselmaterial heraus, behandeln Sie ihn als Option nur für die Entwicklungsumgebung.

Ist es sicher, eine Mitschnittdatei an einen externen Support zu schicken?

Sie unverändert zu schicken ist gefährlich. Ein Mitschnitt enthält die Kommunikation selbst und kann Anmeldedaten aus Klartextprotokollen, Cookies, API-Schlüssel und personenbezogene Daten enthalten. Zuerst, zur Mitschnittzeit, engen Sie Filter und Zeitfenster auf das nötige Minimum ein, und bevor Sie übergeben, extrahieren Sie nur die Zielunterhaltung mit einem Wireshark-Anzeige-Filter und exportieren sie. Für das, was bleibt, vereinbaren Sie mit dem Empfänger den Umgang mit sensiblen Teilen (Maskieren oder auf anderem Weg liefern), bevor Sie senden. Legen Sie im Voraus fest, wie lange Mitschnittdateien aufbewahrt und wann sie gelöscht werden.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.