🚀 go-pugleaf

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

>Hallo,

>ich habe unseren Server heute von Kernel 2.0.27 auf 2.0.33 upgedatet und
>habe seitdem das Problem, dass ich beispielsweise den SMTP-Port von
>saemtlichen entfernten Rechners nicht mehr ansprechen kann, wenn vorher
>mehrfach das Ansprechen dieses Ports auf irgendeinem entfernten Rechner
>schiefgegangen ist.

>Wo koennte das Problem liegen?

Seit .31 ist syn-flood protection (kernel-option hei"st syn-cookies
oder so) drin, da w"urde ich anfangen zu suchen...

  Gerd

-- 
Gerd Knorr <kraxel@cs.tu-berlin.de>

Hallo Gerd <kraxel@cs.tu-berlin.de>,

> Seit .31 ist syn-flood protection (kernel-option hei"st syn-cookies
> oder so) drin, da w"urde ich anfangen zu suchen...

leider hilft weder das Ein- noch das Ausschalten der IP SYN cookies
im Networking-Teil der Kernelkonfiguration (anschliessende Neu-
Compilation und -Installation natuerlich selbstverstaendlich).

Irgendwie scheint es aber wirklich damit zusammenzuhaengen, denn
seitdem diese Option im Kernel ist (wie gesagt, egal ob ein- oder
ausgeschaltet), habe ich mit den Kernels diese Probleme.

Hilfe...?!

Shalom!
  .\ndreas

-- 
                  * Aus dem Spektrum der Moeglichkeiten *
___________________________________________________________________________
    cid  -  christlicher internet dienst       Tel/Fax: ++49-30-4616146
            Schoenwalder Strasse 21            WWW: http://www.cid.net/
            D - 13347 Berlin                   eMail: edler@cid.net

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

> 
> Hallo,
> 
> ich habe unseren Server heute von Kernel 2.0.27 auf 2.0.33 upgedatet und
> habe seitdem das Problem, dass ich beispielsweise den SMTP-Port von
> saemtlichen entfernten Rechners nicht mehr ansprechen kann, wenn vorher
> mehrfach das Ansprechen dieses Ports auf irgendeinem entfernten Rechner
> schiefgegangen ist.

Das klingt so als ob deine Software nicht SO_REUSEADDR verwendet.
> 
> 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?

Grundsaetzlich vermute ich eher eine Fehlkonfiguration als einen Bug,
da einen solch fundamentalen Bug viel mehr Leute bemerkt haetten muessten.

-Andi

Hallo ak@muc.de,

> > 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?

scheinbar kann ich auf den ganzen Host nicht mehr zugreifen, jedenfalls
schlugen den telnet-Versuche auf unterschiedliche Ports fehl.  Ein
traceroute und ping kommt allerdings noch durch.

Ein verkorkster Firewall?  Ich habe gerade den Host wieder auf Kernel
2.0.27 downgegradet, und nun habe ich keinerlei Probleme mehr.

Finde ich irgendwie eigenartig.

Shalom!
  .\ndreas

-- 
                  * Aus dem Spektrum der Moeglichkeiten *
___________________________________________________________________________
    cid  -  christlicher internet dienst       Tel/Fax: ++49-30-4616146
            Schoenwalder Strasse 21            WWW: http://www.cid.net/
            D - 13347 Berlin                   eMail: edler@cid.net

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?

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?

Falls ja, wie kann ich das abschalten und/oder die Funktion unem-
pfindlicher machen?

Wie gesagt, alles Vermutungen und Fragen.

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.

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

Shalom!
  .\ndreas

-- 
   Leben ist Begegnung! Von Mensch zu Mensch - zwischen Gott und Mensch.
___________________________________________________________________________
    cid  -  christlicher internet dienst       Tel/Fax: ++49-30-4616146
            Schoenwalder Strasse 21            WWW: http://www.cid.net/
            D - 13347 Berlin                   eMail: edler@cid.net

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