[linux-l] ftp lahmt

[Steffen Dettmer]

* Peter Ross wrote on Mon, Nov 26, 2007 at 10:26 +1100:
> Ein TCP-reset ist Teil einer TCP-verbindung, d.h. man antwortet auf 
> TCP-Ebene.
> 
> Wenn aber kein Daemon läuft, sollte gar keine TCP-Verbindung aufgebaut 
> werden, deshalb eine Antwort auf ICMP-Ebene.

Stimmt das wirklich?

Ich würde erwarten, dass der Aufbau einer TCP-Verbindung (SYN, noACK)
mit Reset (RST) abgelehnt wird. ICMP seh ich eher zur Kontrolle von IP
als von TCP.

http://www.faqs.org/rfcs/rfc793.html

  SYN-RECEIVED STATE

    If the RST bit is set

       "If this connection was initiated with a passive OPEN (i.e., came
	from the LISTEN state), then return this connection to LISTEN
	state and return.  The user need not be informed.  If this
	connection was initiated with an active OPEN (i.e., came from
	SYN-SENT state) then the connection was refused, signal the user
        "connection refused"."

und auch "Reset processing" verstehe ich so, dass RST die richtige
Antwort ist, wenn kein Daemon läuft, bzw. ein actives OPEN gegen einen
remote Port geht, der nicht LISTEN ist, also keine Verbindungen annimmt
(und da ja keine Connection da sein kann, muss nach "Reset processing"
auch RST gesendet werden).

> http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf
> 
> stellt fest, daß viele Verbindungen nicht mehr TCP-Standards folgen, z.B. 
> viele HTTP-Verbindungen sind fehlerhaft implementiert und benutzen 
> TCP-Resets sinnentstellend.

Das Dokument verstehe ich anders, hab es aber auch nur überflogen.

Erstmal wird der Fall "REJ" nur als Verbindungsfehler (nicht als
Browserfehler) genannt, dann als Beispiel auch der Serverumzug genannt
(wobei REJ bei Verbindungen zur alten IP ohne Webserver meiner Erwartung
entspricht und das passt IMHO zur Aussage im Dokument, obwohl es nicht
wirklich klar ist) und letztlich ist meiner Meinung nach die
Kernaussage, dass die Fehler "RSTO" und "RSTR", besonders ersters, das
interessante Problem seien.

Überhaupt schreibt das Dokument doch eigentlich nur

  "On connections using IE as the Browser, the client typically
   responded with a RST, rather than completing the FIN handshake."

  (FIN ist ein Flag im Verbindungsabbau)

Kurz: Der IE ist buggy.

Möglicherweise "traute" sich das Dokument nur einfach nicht, dass so
kurz und hart zu sagen. Die einzigen anderen systematischen Fehler, die
ich finden konnte, bezogen sich auf IIS, ebenfalls ein Windows-only
MicroSoft-Produkt.

Oder verstehe ich das falsch?

> Das Howto dürfte auch falsch sein, IMHO.
> 
> Ich sehe das gerade sogar in der iptables-Manpage.. Grrrh.
> 
> "The option tcp-reset can be used on rules which only match the TCP 
> protocol: this causes a TCP RST packet to be sent back.  This is mainly 
> useful for blocking ident (113/tcp) probes which frequently occur when 
> sending mail to broken mail hosts (which won't accept your mail 
> otherwise)."
> 
> Keine Ahnung, welcher Mail-Server so kaputt ist, daß nicht mal ein ICMP 
> reicht:-( 

Was für eine ICMP Message sollte gesendet werden? Type 3 mit "port
unreachable"? Aber das wäre ja falsch, er ist ja erreichbar, es macht
nur gerade keiner ein LISTEN.

Wobei mich wundert, warum man da ne Firewallregel macht, das Verhalten
ist doch schon genau so? Oder geht es darum, dass man trozdem einen
identd laufen lassen kann und keinen tcpwrapper mehr konfigurieren muss?
tcpwrapper sind oft mächtiger als Firewalls, aber total out. Warum
eigentlich? Weils die bei Windows nicht gibt?

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.