[HaBo]

Badlands92

Anzeige

Hi Leute,

ich teste gerade den scanner NMAP unter Linux und bekomme beim scannen immer wieder Zwischenmeldungen, die scheinbar vom Betriebssystem her kommen: "RTTVAR has grown to over 2.3 seconds, decreasing to 2.0 adjust_timeout: packet supposedly had rtt of 9006848 microseconds. Ignoring time."

Mir sind änliche Meldungen nur untergekommen, wenn zuviele Prozesse auf einmal laufen. Allerdings läuft hier nur ein Prozess von NMAP. Weis jemand was mir der Rechner damit sagen will? Abgesehen davon das er mir zeigen will das ich noch einiges lernen muss.

Gruß
Badlands92

Armitage

Zu NMAP...
Alles was Du wissen musst bringt Dir der Befehl ::

man nmap


*rtfm*...)
:wq!

Rushjo

@Badlands92

Schau erstmal, wie seth gesagt hat, Dir die möglichen
Befehle für nmap mit 'man nmap' an! Desweiteren
benötigt nmap für einige Scans z.B. stealth-scan
root-rechte, sprich diese Scans können nur durch
den Admin oder User mit root-Rechten durchgeführt
werden. Aber wenn dies der Fehler wäre, dann
würde nmap es Dir schon sagen! Ich würde darauf
tippen, das nmap entweder nicht richtig oder unvoll-
ständig installiert ist! Welche Distributuion und
welche Version von Nmap nutzt Du denn?

MfG Rushjo

P.S. Ich nutze meistensals Befehl (Stealth-Scan):

nmap -v -v -sS -O -P0 'xxx.xxx.xxx.xxx' xxx.xxx.xxx.xxx

Badlands92

@Rushjo und @Seth

Natürlich habe ich mir die Manpages von NMAP angeschaut!
Ich habe auch schon versucht mittels der Option --inititial_rtt_timeout und --max_rtt_timeout das Problem in den Griff zu bekommen. Jedoch ohne erfolg. Snifft man den Netzwerkverkehr mit, fällt auf das einige ICMP unrechabels Messages dabei sind. Diese bekomme ich von einem Rechner vor meinem Zielhost. Überraschender weise bekomme ich die ICMP Meldungen nur wenn ich über DSL/Netzwerkkarte gehe und nicht wenn ich mich mittels ISDN einwähle (bei ISDN auch keine RTTVAR Meldungen). NMAP besitzt auch root-rechte auch das habe ich bereits überprüft. Meine Nachforschungen zu RTTVAR ergaben, das es sich dabei um einen Retransmission Parameter handelt, der abläuft, wenn ein Paket während einer TCP/IP-Verbindung verloren geht. Nur ist dies ja bei einem Scan, wenn der Port dicht bzw. nicht in gebrauch ist, ja sehr häufig der Fall. Außerdem handelt es sich doch bei der Option -sT um einen vollständigen Drei-Wege-Handschlag. Die einzige Zeit die ablaufen sollte, ist der Parameter für den Verbindungsaufbau. Aber evtl. ist dieser Parameter ja identisch. Habe ich jedoch noch nicht herausgefunden. Eine weitere möglichkeit ist sicherlich, das ein Router auf dem Weg zum Rechner einfach überflutet wird. Kann man dies eigentlich irgendwie feststellen?

Gruß
Badlands92

DocZimmermann

Hi,
Übersetz dei Fehlermeldung doch einfach mal ins Deutsche und du weißt was los ist.
RTTVAR has grown to over 2.3 seconds

Round-Trip-Time angestiegen auf über 2,3 Sec.
Also die Geschwindigkeit zu deinem Ziel ist zu langsam geworden.
Dadurch hat er einen Time Out eingeleitet!

( So interprtiere ich diese Meldung, verbessert mich wenns nicht so ist )
Gruß
The Doc

Badlands92

@DocZimmermann

Das ist mir schon klar Doc. Das Problem liegt aber wohl tiefer. Bei einem Portscann bekomme ich automatisch von den meisten Ports keine Rückmeldung. Die Variable läuft also so bei einem standard Webserver der nur auf Port 80 reagiert 65534 mal ab. Dies ist aber nicht der Fall, da die Meldung "RTTVAR has grown...." normalerweise nicht kommt. Zumindest bei mir nicht. Wenn sie jedesmal hochgezählt werden würde, würde ein simpler Portscann mittels NMAP ewig dauern.
Wenn ein Router auf dem Weg zum Zielhost Traffic-Probleme hat, so würde er nach meinem verstehen, mir ICMP Source Quench Meldungen schicken.
Die bekomme ich aber nicht. Ich bekomme über DSL ICMP Destination Unreachable Messages mit dem Code 10 Communication with Destination Host is
Administratively Prohibited. Was aber von einem System vor meinem Zielhost kommt. Erst dann fangen die RTTVAR-Meldungen an. Also gehe ich davon aus das diese Meldungen meinen TCP/IP-Stack aus dem Gleichgewicht bringen. Nur weis ich nicht warum. Oder es leigt halt an NMAP. Der Kernel den ich unter GNU/Linux benutze hat zumindest in dieser Beziehung keinen Fehler. Na ja zumindest offiziel

Gruß
Badlands92