Jemand schickte mir die folgende Aufzeichnung und fragte, ob es sich um erneute Übertragungen handele, da die "Paketnummern" doppelt vorhanden seien
T 0536 TCP host.subdomain.domain.com host2.sub2.dom2.com 49957 4000 A T 0536 TCP host.subdomain.domain.com host2.sub2.dom2.com 49957 4000 A T 0536 TCP host.subdomain.domain.com host2.sub2.dom2.com 49957 4000 A T 0536 TCP host.subdomain.domain.com host2.sub2.dom2.com 49957 4000 A T 0536 TCP host.subdomain.domain.com host2.sub2.dom2.com 49957 4000 A T 0486 TCP host.subdomain.domain.com host2.sub2.dom2.com 49957 4000 PA R 0000 TCP host2.sub2.dom2.com host.subdomain.domain.co 4000 49957 A R 0000 TCP host2.sub2.dom2.com host.subdomain.domain.co 4000 49957 A R 0000 TCP host2.sub2.dom2.com host.subdomain.domain.co 4000 49957 A R 0000 TCP host2.sub2.dom2.com host.subdomain.domain.co 4000 49957 A R 0044 TCP host2.sub2.dom2.com host.subdomain.domain.co 4000 49957 PA T 0536 TCP host.subdomain.domain.com host2.sub2.dom2.com 49957 4000 A T 0536 TCP host.subdomain.domain.com host2.sub2.dom2.com 49957 4000 A T 0536 TCP host.subdomain.domain.com host2.sub2.dom2.com 49957 4000 A
Ich war etwas verwirrt durch ihre Verwendung von "Paketnummern"; sie bezog sich auf die letzten beiden numerischen Spalten. Ich erklärte ihr, dass es sich dabei um die Nummern der Quell- und Zielports handelt, nicht um Paketnummern. Leider konnte ich ihre Frage nicht beantworten, da sie nicht genügend Informationen aus dem TCP-Paketkopf erfasst hatte, um sagen zu können, ob es sich um erneute Übertragungen handelt oder nicht.
Um festzustellen, ob es sich bei einem TCP-Paket um eine erneute Übertragung handelt, müssen Sie die Sequenznummer des Pakets erfassen. Zu Beginn jeder TCP-Verbindung wählen die beiden Hosts zufällige Sequenznummern aus und erhöhen dann die Sequenznummer für jedes Byte an TCP-Daten, das sie senden. Der empfangende Host sendet im Bestätigungsfeld die Sequenznummer zurück, die er als Nächstes zu sehen erwartet.
Das folgende Beispiel zeigt, was ich als minimalen Satz von Kontrollargumenten für packet_monitor empfehle; vorausgesetzt, Sie sind an mehr interessiert als nur an der Information, dass ein Paket gesendet oder empfangen wurde. Das Argument interface identifiziert die zu überwachende IP-Schnittstelle. Wenn Sie keinen Schnittstellennamen angeben, wird packet_monitor alle Schnittstellen überwachen. Packet_monitor kann eine große Menge an Streamspeicher verwenden, die Verwendung des Interface-Arguments hilft, diese Menge zu reduzieren. Mit dem Argument -verbose werden die Sequenz- und Acknowledgment-Nummern ausgegeben, da es sonst keine Möglichkeit gibt, Wiederholungen zu identifizieren. Es gibt auch andere Informationen aus, die bei der Analyse von Traces nützlich sind, z. B. die Werte für Time to Live (TTL) und Window Size (Window). Die Argumente -filter -host und -port helfen bei der Identifizierung einer bestimmten Verbindung und reduzieren die Anzahl der Pakete, die Sie sich ansehen müssen.
packet_monitor -interface #sdlmux.m16.11-2 -verbose -filter -host 172.16.1.34 -p +ort 23 dir icmp typ tcp dir len proto Quelle Ziel src port dst port type Xmit IP Ver/HL 45, ToS 0, Len 29, ID 8569, Flg/Frg 0, TTL 3c, Prtl 6 Cksum 9eaf, Src ac100174, Dst ac100122 TCP von phx_vos-m16.51094 an 172.16.1.34.telnet seq 448953077, ack 1766884569, window 65535, 1 Datenbytes, Flags Push Ack. X/Off 05, Flags 18, Cksum 9c85, Urg-> 0000
Rcvd IP Ver/HL 45, ToS 0, Len 29, ID 45db, Flg/Frg 0, TTL 3c, Prtl 6 Cksum de3d, Src ac100122, Dst ac100174 TCP von 172.16.1.34.telnet an phx_vos-m16.51094 seq 1766884569, ack 448953078, window 8192, 1 Datenbytes, Flags Push Ack. X/Off 05, Flags 18, Cksum c984, Urg-> 0000
Xmit IP Ver/HL 45, ToS 0, Len 29, ID 8576, Flg/Frg 0, TTL 3c, Prtl 6 Cksum 9ea2, Src ac100174, Dst ac100122 TCP von phx_vos-m16.51094 an 172.16.1.34.telnet seq 448953078, ack 1766884570, window 65535, 1 Datenbytes, Flags Push Ack. X/Off 05, Flags 18, Cksum d883, Urg-> 0000
Rcvd IP Ver/HL 45, ToS 0, Len 29, ID 45dc, Flg/Frg 0, TTL 3c, Prtl 6 Cksum de3c, Src ac100122, Dst ac100174 TCP von 172.16.1.34.telnet an phx_vos-m16.51094 seq 1766884570, ack 448953079, window 8192, 1 Datenbytes, Flags Push Ack. X/Off 05, Flags 18, Cksum c982, Urg-> 0000
Xmit IP Ver/HL 45, ToS 0, Len 28, ID 8580, Flg/Frg 0, TTL 3c, Prtl 6 Cksum 9e99, Src ac100174, Dst ac100122 TCP von phx_vos-m16.51094 an 172.16.1.34.telnet seq 448953079, ack 1766884571, window 65535, 0 Datenbytes, Flags Ack. X/Off 05, Flags 10, Cksum 098b, Urg-> 0000
Rcvd IP Ver/HL 45, ToS 0, Len 28, ID 45dd, Flg/Frg 0, TTL 3c, Prtl 6 Cksum de3c, Src ac100122, Dst ac100174 TCP von 172.16.1.34.telnet an phx_vos-m16.51094 seq 1766884571, ack 448953079, window 8192, 0 Datenbytes, Flags Ack. X/Off 05, Flags 10, Cksum e98a, Urg-> 0000
Die obigen Sequenznummern werden um 1 erhöht, da jedes Paket nur 1 Byte an Daten enthält. Würden die Pakete 10 Bytes, 23 Bytes oder 1023 Bytes enthalten, würden die Sequenznummern um 10, 23 oder 1023 steigen.
Wie sieht also eine erneute Übertragung aus? Bei einer erneuten Übertragung ist die Sequenznummer entweder kleiner oder gleich der vorherigen Sequenznummer und enthält mindestens 1 Byte an Daten; Pakete ohne Daten zählen nicht. Im folgenden Beispiel wird die Sequenznummer 448953089 mehrfach wiederholt. Jedes Mal außer dem ersten Mal ist eine erneute Übertragung.
packet_monitor -interface #sdlmux.m16.11-2 -verbose -filter -host 172.16.1.34 -p +ort 23 dir icmp typ tcp dir len proto quelle ziel src port dst port typ
Rcvd IP Ver/HL 45, ToS 0, Len 28, ID 4d43, Flg/Frg 0, TTL 3c, Prtl 6 Cksum d6d6, Src ac100122, Dst ac100174 TCP von 172.16.1.34.telnet an phx_vos-m16.51094 seq 1766885133, ack 448953089, window 8192, 0 Datenbytes, Flags Ack. X/Off 05, Flags 10, Cksum e74e, Urg-> 0000
Xmit IP Ver/HL 45, ToS 0, Len 29, ID 9191, Flg/Frg 0, TTL 3c, Prtl 6 Cksum 9287, Src ac100174, Dst ac100122 TCP von phx_vos-m16.51094 an 172.16.1.34.telnet seq 448953089, ack 1766885133, window 65535, 1 Datenbytes, Flags Push Ack. X/Off 05, Flaggen 18, Cksum 9745, Urg-> 0000
Xmit IP Ver/HL 45, ToS 0, Len 29, ID 919a, Flg/Frg 0, TTL 3c, Prtl 6 Cksum 927e, Src ac100174, Dst ac100122 TCP von phx_vos-m16.51094 an 172.16.1.34.telnet seq 448953089, ack 1766885133, window 65535, 1 Datenbytes, Flags Push Ack. X/Off 05, Flaggen 18, Cksum 9745, Urg-> 0000
Xmit IP Ver/HL 45, ToS 0, Len 29, ID 91a0, Flg/Frg 0, TTL 3c, Prtl 6 Cksum 9278, Src ac100174, Dst ac100122 TCP von phx_vos-m16.51094 an 172.16.1.34.telnet seq 448953089, ack 1766885133, window 65535, 1 Datenbytes, Flags Push Ack. X/Off 05, Flaggen 18, Cksum 9745, Urg-> 0000
. . .
Xmit IP Ver/HL 45, ToS 0, Len 29, ID 91f9, Flg/Frg 0, TTL 3c, Prtl 6 Cksum 921f, Src ac100174, Dst ac100122 TCP von phx_vos-m16.51094 an 172.16.1.34.telnet seq 448953089, ack 1766885133, window 65535, 1 Datenbytes, Flags Push Ack. X/Off 05, Flaggen 18, Cksum 9745, Urg-> 0000
Rcvd IP Ver/HL 45, ToS 0, Len 29, ID 4f04, Flg/Frg 0, TTL 3c, Prtl 6 Cksum d514, Src ac100122, Dst ac100174 TCP von 172.16.1.34.telnet an phx_vos-m16.51094 seq 1766885133, ack 448953090, window 8192, 1 Datenbytes, Flags Push Ack. X/Off 05, Flags 18, Cksum 7744, Urg-> 0000
Neben den Argumenten interface und verbose würde ich die Argumente time_stamp und numeric hinzufügen. Das time_stamp-Argument versieht jedes angezeigte Paket mit einem Zeitstempel, was die Korrelation von Meldungen in Protokolldateien mit dem Trace erleichtert und es ermöglicht, abzuschätzen, wie lange Ereignisse wie eine erneute Übertragungssequenz tatsächlich dauern. Das numerische Argument reduziert den Overhead, da keine Host- oder Portnamen nachgeschlagen werden müssen.
packet_monitor -interface #sdlmux.m16.11-2 -verbose -time_stamp -numeric -filter + -Host 172.16.1.34 -Port 23 dir icmp type + tcp hh:mm:ss.ttt dir len proto Quelle Ziel src port ds +t port typ 14:30:17.604 Xmit IP Ver/HL 45, ToS 0, Len 29, ID 9b7b, Flg/Frg 0, TTL 3 +c, Prtl 6 Cksum 889d, Src ac100174, Dst ac100122 TCP von 172.16.1.116.51094 an 172.16.1.34.telnet seq 448953090, ack 1766885134, window 65535, 1 Datenbytes, Flags Push Ack. X/Off 05, Flags 18, Cksum 9b43, Urg-> 0000
14:30:17.606 Rcvd IP Ver/HL 45, ToS 0, Len 29, ID 5442, Flg/Frg 0, TTL 3 +c, Prtl 6 Cksum cfd6, Src ac100122, Dst ac100174 TCP von 172.16.1.34.telnet nach 172.16.1.116.51094 seq 1766885134, ack 448953091, window 32768, 1 Datenbytes, Flags Push Ack. X/Off 05, Flags 18, Cksum 1b42, Urg-> 0000
Wenn Sie wissen, dass das Problem auf der TCP- oder IP-Schicht liegt, ist das in der Regel alles, was Sie brauchen. Wenn das Problem jedoch auf der Anwendungsschicht liegen könnte, benötigen Sie auch die tatsächlichen Daten. Sie können sich die Daten mit dem Argument -hex_dump anzeigen lassen. Standardmäßig werden nur die ersten 128 Bytes der Daten angezeigt. Um auf Nummer sicher zu gehen, setze ich length immer auf 1500, wodurch alle Daten des Pakets angezeigt werden.
packet_monitor -interface #sdlmux.m16.11-2 -verbose -time_stamp -numeric -hex_du +mp -Länge 1500 -filter -host 172.16.1.34 -port 23 dir icmp typ + tcp hh:mm:ss.ttt dir len proto Quelle Ziel src port ds +t port typ 10:25:19.387 Rcvd IP Ver/HL 45, ToS 0, Len 3b, ID f8f, Flg/Frg 0, TTL 3 +c, Prtl 6 Cksum 1478, Src ac100122, Dst ac100174 TCP von 172.16.1.34.49562 an 172.16.1.116.telnet seq 110526313, ack 1206659552, window 32768, 19 Datenbytes, Flags Push Ack +. X/Off 05, Flags 18, Cksum d3ee, Urg-> 0000 Offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C... 0 54 68 69 73 20 69 73 20 6f 6e 6c 79 20 61 20 74 * Dies ist nur ein t 10 65 73 74 * est
10:25:19.389 Xmit IP Ver/HL 45, ToS 0, Len 3b, ID f969, Flg/Frg 0, TTL 3 +c, Prtl 6 Cksum 2a9d, Src ac100174, Dst ac100122 TCP von 172.16.1.116.telnet nach 172.16.1.34.49562 seq 1206659552, ack 110526332, window 8192, 19 Datenbytes, Flags Push Ack +. X/Off 05, Flags 18, Cksum 33dc, Urg-> 0000 Offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C... 0 54 68 69 73 20 69 73 20 6f 6e 6c 79 20 61 20 74 * Dies ist nur ein t 10 65 73 74 * est
10:25:22.263 Xmit IP Ver/HL 45, ToS 0, Len 28, ID f994, Flg/Frg 0, TTL 3 +c, Prtl 6 Cksum 2a85, Src ac100174, Dst ac100122 TCP von 172.16.1.116.telnet nach 172.16.1.34.49562 seq 1206659571, ack 110526332, window 8192, 0 Datenbytes, Flags Ack. X/Off 05, Flags 10, Cksum 7b7a, Urg-> 0000 Keine tcp-Daten.
Bevor Sie einen packet_monitor-Trace mit Daten an jemanden senden, denken Sie daran, die Daten zu bereinigen - sowohl Text als auch Hex-Werte, um geschützte Informationen zu entfernen. Unter bestimmten Umständen sollten Sie auch die IP-Adressen bereinigen. Die IP-Adressen kommen an zwei Stellen vor: In der Zeile für die Dekodierung des Protokoll-Headers erscheinen sie in standardmäßiger punktierter Dezimaldarstellung. In der Zeile unmittelbar über der Dekodierzeile erscheinen sie als Hex-Werte.
10:25:22.263 Xmit IP Ver/HL 45, ToS 0, Len 28, ID f994, Flg/Frg 0, TTL 3 +c, Prtl 6 Cksum 2a85, Src ac100174, Dst ac100122 TCP von 172.16.1.116.telnet nach 172.16.1.34.49562 seq 1206659571, ack 110526332, window 8192, 0 Datenbytes, Flags Ack. X/Off 05, Flags 10, Cksum 7b7a, Urg-> 0000 Keine tcp-Daten.
Unternehmen