FIN_WAIT_2 Timeout

[Florian88]

Hallo,

ich habe einige FreeBSD und einige OpenBSD ftp-Server am Laufen. Auf beiden Systemen läuft pf.

Wenn ich Dateien downloade und dabei auf dem Server die States beobachte tritt folgender Sachverhalt auf:

Nachdem der Download beendet ist, endet die Verbindung mit State FIN_WAIT_2:FIN_WAIT_2 und timt nach 90 Sekunden aus. Es treten keine weiteren Probleme auf, dennoch wüsste ich gerne warum die Verbindung nicht regulär beendet wird. Wenn ein Benutzer viele kleine Dateien downloadet und einen Downloadmanager benutzt habe ich bis zu 9000 FIN_WAIT_2 States gleichzeitig.
Ich weiß dass ich die States pro IP begrenzen kann, aber wieso werden die Verbindungen nicht, wie in RFC 793 vorgesehen beendet?

Laut RFC sollte eine Verbindung so beendet werden:

    TCP A                                                TCP B

  1.  ESTABLISHED                                          ESTABLISHED

  2.  (Close)
      FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  --> CLOSE-WAIT

  3.  FIN-WAIT-2  <-- <SEQ=300><ACK=101><CTL=ACK>      <-- CLOSE-WAIT

  4.                                                       (Close)
      TIME-WAIT   <-- <SEQ=300><ACK=101><CTL=FIN,ACK>  <-- LAST-ACK

  5.  TIME-WAIT   --> <SEQ=101><ACK=301><CTL=ACK>      --> CLOSED

  6.  (2 MSL)
      CLOSED

Ich habe mitgesniffert und bei mir siehts (ich habe mehrere Betriebssysteme und mehrere Clients probiert) so aus:

Server -> Client: Fin,Ack
Client -> Server: Fin,Ack
FIN_WAIT_2:FIN_WAIT_2

Hat jemand eine Ahnung warum das so ist?
Würde mich echt interessieren.

Grüße
Florian

 

[nakal]

Ich kann mir vorstellen, dass so etwas auch an defekten oder falsch eingestellten Paketfiltern liegen kann. Ich würde mal Logging beim Server+Client anschalten und schauen was da im Paketfilter hängen bleibt.

 

[Florian88]

Hallo nakal,
hast ja heute Nacht echt schnell geantwortet, aber mir wars etwas spät um noch an der Firewallconfig rumzufummeln.

Ich habe vorhin auf beiden Seiten die Firewall ausgeschaltet und mitgesniffert, auch hier wird vom Server nur ein Fin,Ack gesendet und mit einem Fin,Ack beantwortet.

Auch pflog habe ich probiert, da bleiben keine Pakete hängen.

Hat jemand die Möglichkeit das beschriebene Verhalten zu reproduzieren?
Weiß jemand ob das ein Fehler ist oder ob es einen Grund hat warum der State noch 90 Sekunden besteht?

 

[kai_001]

Ich glaube die beiden Systemvariablen haben damit was zu tun ...

net.inet.tcp.keepidle und net.inet.tcp.keepintvl

Eventuell mal kurz googeln, dazu findet sich ne Menge ...

Gruß
Kai

 

[morromett]

http://www.gnugk.org/keepalive.html

net.inet.tcp.keepidle - Amount of time, in milliseconds, that the (tcp)
connection must be idle before keepalive probes (if enabled) are sent.

net.inet.tcp.keepintvl - The interval, in milliseconds, between
keepalive probes sent to remote machines. After TCPTV_KEEPCNT (default
8) probes are sent, with no response, the (tcp)connection is dropped.

net.inet.tcp.always_keepalive - Assume that SO_KEEPALIVE is set on all
TCP connections, the kernel will periodically send a packet to the
remote host to verify the connection is still up.

therefore formula to calculate maximum TCP inactive connection time is
following:

net.inet.tcp.keepidle + (net.inet.tcp.keepintvl x 8)

the result is in milliseconds.

therefore, by setting
net.inet.tcp.keepidle = 10000
net.inet.tcp.keepintvl = 5000
net.inet.tcp.always_keepalive =1 (must be 1 always)

the system will disconnect a call when TCP connection is dead for:
10000 + (5000 x 8) = 50000 msec (50 sec)

To make system remember these settings at startup, you should add them
to /etc/sysctl.conf file