WinDump und dessen Aussgabe in eine Datei
Hallo zusammen,
aktuell beschäftigt mich ein eigentlich kleines Netzwerkproblem zwischen einem Webbrowser und einem Webserver. Zur automatischen Analyse der Fehler und auch zur statistischen Erfassung setzte ich bis jetzt auf WinDump. Mit folgendem Befehl habe ich die Packete jeweils eerfasst:
windump -i 4 -w c:\1.txt -n src host 10.20.3.13 and dst host 10.20.3.101 and tcp port 80
Ausgedeutscht also Erfassen der Pakete vom Interface 4 ins File c:\1.txt vom host 10.20.3.13 zum server 10.20.3.101 (wo Windump läuft) auf Port 80
Eigentlich funktiniert das weitgehend, ich bekomme nämlich dann das folgende Resultat :
Bei gewissen Anfragen in meiner speziellen Anwendung ist der String nach dem GET aber bedeutend länger und enthält einige Variablen welche ich gerne auswerten möchte, im 1.txt wird ein Teil der benötigten Variablen korrekt dargestellt, der Rest aber irgendwie kryptisch dargestellt (nach dem letzten %V), bzw. abgeschnitten:
Hat jemand eine Idee, an was das liegen kann?
Oder hat jemand eine bessere Idee, wie isch die Daten am einfachsten in ein File geschrieben bekomme, muss nicht zwingend WindUmp sein...?
Danke, Gruss Simon
aktuell beschäftigt mich ein eigentlich kleines Netzwerkproblem zwischen einem Webbrowser und einem Webserver. Zur automatischen Analyse der Fehler und auch zur statistischen Erfassung setzte ich bis jetzt auf WinDump. Mit folgendem Befehl habe ich die Packete jeweils eerfasst:
windump -i 4 -w c:\1.txt -n src host 10.20.3.13 and dst host 10.20.3.101 and tcp port 80
Ausgedeutscht also Erfassen der Pakete vom Interface 4 ins File c:\1.txt vom host 10.20.3.13 zum server 10.20.3.101 (wo Windump läuft) auf Port 80
Eigentlich funktiniert das weitgehend, ich bekomme nämlich dann das folgende Resultat :
Bei gewissen Anfragen in meiner speziellen Anwendung ist der String nach dem GET aber bedeutend länger und enthält einige Variablen welche ich gerne auswerten möchte, im 1.txt wird ein Teil der benötigten Variablen korrekt dargestellt, der Rest aber irgendwie kryptisch dargestellt (nach dem letzten %V), bzw. abgeschnitten:
Hat jemand eine Idee, an was das liegen kann?
Oder hat jemand eine bessere Idee, wie isch die Daten am einfachsten in ein File geschrieben bekomme, muss nicht zwingend WindUmp sein...?
Danke, Gruss Simon
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 184371
Url: https://administrator.de/contentid/184371
Ausgedruckt am: 19.11.2024 um 22:11 Uhr
2 Kommentare
Neuester Kommentar
Hallo
sieht so aus als ob windump ein tcpdump für Windows ist...
-s
Snarf snaplen bytes of data from each packet rather than the default of 68 (with SunOS's NIT, the minimum is actually 96). 68 bytes is adequate for IP, ICMP, TCP and UDP but may truncate protocol information from name server and NFS packets (see below). Packets truncated because of a limited snapshot are indicated in the output with ``[|proto]'', where proto is the name of the protocol level at which the truncation has occurred. Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering. This may cause packets to be lost. You should limit snaplen to the smallest number that will capture the protocol information you're interested in. Setting snaplen to 0 means use the required length to catch whole packets.
Also sowas wie "-s 1600" als Parameter angeben.
Gruß
Andi
sieht so aus als ob windump ein tcpdump für Windows ist...
-s
Snarf snaplen bytes of data from each packet rather than the default of 68 (with SunOS's NIT, the minimum is actually 96). 68 bytes is adequate for IP, ICMP, TCP and UDP but may truncate protocol information from name server and NFS packets (see below). Packets truncated because of a limited snapshot are indicated in the output with ``[|proto]'', where proto is the name of the protocol level at which the truncation has occurred. Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering. This may cause packets to be lost. You should limit snaplen to the smallest number that will capture the protocol information you're interested in. Setting snaplen to 0 means use the required length to catch whole packets.
Also sowas wie "-s 1600" als Parameter angeben.
Gruß
Andi