🚀 go-pugleaf

Andreas Edler <aed@cid-net.de> writes:

> 
> ak@muc.de schrieb:
> 
> >> Beispiel:  Mailauslieferung brachte einen Timeout.  Anschliessend bekomme
> >> ich keine einzige Mail mehr aus dem lokalen Netz, netstat zeigt SYN_SENT
> >> an.
> 
> > d.h. TCP bekommt keine Antwort mehr von draussen. Koennte ein Routingproblem
> > oder ein verkorkster Firewall sein. Kannst du die entsprechenden Hosts 
> > dann noch pingen? Was zeigt netstat -t -a ueber den anderen Host an?
> > Kannst du auf andere Ports auf dem Host zugreifen?
> 
> Kann es sein (Vermutung und Frage!), dass Linux im Kernel eine Funktio-
> nalitaet hat, dass falls ein Host bei der Kommunikation einen zu haeufigen
> Timeout hat, diesen Host dann erstmal fuer eine gewisse Zeit sperrt?

Nein. Nicht direkt. Das einzige was existiert ist der sogenannte
TIME_WAIT state (2 Minuten). Die meisten Rechner (mit BSD basierten
Stacks, Linux auch) unterstuetzen auch neue Verbindungen direkt aus
TIME_WAIT heraus. TIME_WAIT gilt allerdings nicht fuer ganze Hosts
sondern nur fuer sourceport/sourceaddress/zielport/ zieladdress
Kombinationen.

> 
> Und weiter, kann es sein, dass diese Funktionalitaet erst ab Kernel
> hoeher 2.0.27 (mindestens ab 2.0.30) bekommen hat oder "empfindlicher"
> geworden ist?

Nein. Es gab einige Aenderungen in 2.0.30 fuer eine hoehere
Geschwindigkeit, die sollten sich aber nicht auf TIME_WAIT auswirken
(Betonung auf sollten).  Der originale Poster hat sich ja beharrlich
geweigert genuegend Informationen rauszugeben um irgendein Problem
zu diagnostizieren. Ohne einen verwertbaren tcpdump von moeglichem
Fehlverhalten kann man nicht viel machen.

> Allerdings hatte ich in den letzten Tagen, dass in einem BNC-LAN zwei
> Hosts nicht mehr direkt mit einander "sprechen" wollten, allerdings
> ein anderer Host im gleichen LAN mit allen beiden voellig problemlos
> TCP/IP talken konnte.  Habe dann den Routing-Eintrag fuer das ganze
> Netz geloescht und das Netz somit ueber den Umweg des Default-Routers
> geroutet, und damit funktionierte erstmal wieder alles.  Nach mehreren
> Stunden hatte ich dann mit dem erneuten Setzen des Netzroutings keine
> Probleme mehr, es lief dann alles wieder wie vorher.  Komisch.  Ist
> bisher auch nur mit 2.0.32 und 2.0.33 aufgetreten, und dass immer mal
> wieder.  Mit 2.0.27 habe ich diesbezueglich noch nie Probleme gehabt.

Klingt nach Muell in der ARP Tabelle.

> Gibt es wirklich niemanden, der Ansaetze und Ideen zur Problemloesung
> hat?

Klar. Wenn du ein reproduzierbares Fehlverhalten feststellst mach einen
(bitte nicht zu langen!) tcpdump von der Verbindung und schick den ein.
Was auch interessant ist ist die Sockettabelle fuer TCP (netstat -ta)

-Andi