Hallo Leute,
ich beobachte hier momentan ein Problem mit mldonkey (MLNet 2.5-16w3) unter Debian Sarge Linux, bei dem ich nicht so richtig weiterweiß:
Der Rechner, auf welchem der Esel läuft, hängt direkt hinter einem LANCOM DSL/1610 Office Router. Da passiert folgendes:
Problem ist, daß, wenn ich den mldonkey "wie vorgesehen" via kill tasknummer beende, mein Router den Esel-Port dichtmacht. Nach einiger Beobachtung habe ich folgendes herausgefunden:
Der Router läßt in der Standardkonfiguration ja nur
maximal 100 "halboffene Ports" zu, alles darüber wird als DoS angesehen und verworfen. Ist die Grenze von 100 erreicht, läuft ein 30s-timer, und Ports werden erst wieder abgebaut, wenn keine Anfragen kommen. So weit, so mittelgut. Dieses Verfahren funktioniert bei einem Freund mit LANCOM 1611 (und einem anderen mit einem größeren Modell, Name ist mir entfallen) Router und identischer Konfiguration problemlos, _allerdings_ nutzt er Windows-Eselsoftware.
Ich kenne mich damit jetzt nicht so wirklich aus, aber für mich sieht es wie folgt aus:
Wenn ich nun den mldonkey kille, dann beendet dieser die ganzen Verbindungen nicht korrekt, sondern ist einfach "weg". Also kommen von außen immer weiter Anfragen über Anfragen, und der genannte Schutzmechanismus tritt in Kraft. Problem dabei ist, das ich danach den mldonkey zwar wieder starten kann, er aber erst wieder mit den Servern connectet, wenn ich vorher eine Neueinwahl des DSL-Anschlußes mache, da ja die Esel-Ports "dicht" sind. Da das Ganze bei Windows nicht auftritt (wir haben es unter Beobachtung des Router-Status ausprobiert, dort kommen nach Beendigung der Eselsoftware höchsten noch 10 oder 15 Anfragen, die ins leere laufen), muß es IMO am
verwendeten mldonkey oder an den Router-Einstellungen liegen.
Außerdem ist mir dabei noch aufgefallen, daß dieser Counter den Router auch nach ca. 10 Std. Betrieb "dichtmachen" läßt, sprich dann sind so viele Anfragen aufgekommen, das nix mehr geht (in der Zwischenzeit habe ich bestimmte Files aus dem sharing gelöscht, vermutlich sind es Anfragen bzgl. dieser nicht vorhandenen files).
Ach ja: löse ich z.B. per ssh einen disconnect aus (wobei der Router sich hernach automatisch wieder verbindet) geht das ganze Spiel wieder von vorne los, da ich dann ja auch eine neue IP bekomme.
Aktuelles LCOS 5 ist drauf.
Any hints!?
Gruß
Dirk
EDIT: Standardeinstellung für max. Verbindungen im download ist bei mldonkey 200. Ich könnte die jetzt natürlich verringern, aber das kann ja nicht die Lösung sein, zumal ich da ja die upload-Verbindungen hinzurechnen muß. Und ich hatte nicht vor, insgesamt so schlecht dazustehen, wie wenn ich insgesamt nur 100 Verbindungen erlaube.
mldonkey und LANCOM DSL/1610 Office funktioniert nicht:
Moderator: Lancom-Systems Moderatoren
Hi Dirk,
Offenbar wird dabei der TCP-Listener dabei nicht korrekt gelöscht und einkommende TCP-SYN Pakete werden nicht rejectet sondern der Listener versucht die gekillte Anwendung zu erreichen. Da diese aber nicht mehr existiert wartet der Listener ewig auf eine Antwort und schickt somit weder ein SYN-ACK noch ein RST zurück, was als halboffene Verbindung gezählt wird. Sobald die konfigurierte Grenze (100) überschritten wird, werden weitere Verbindungsversuche auf diesen Port geblockt - und zwar solange bis 30 Sekunden lang keine weitere Anfrage mehr kommt.
Versuch doch mal mldonkey auf korrekte Weise zu beenden - also nicht mit "kill". Dann sollte auch Ruhe sein...
Gruß
Backslash
genau das dürfte dein Problem sein...Problem ist, daß, wenn ich den mldonkey "wie vorgesehen" via kill tasknummer beende, mein Router den Esel-Port dichtmacht. Nach einiger Beobachtung habe ich folgendes herausgefunden:
Offenbar wird dabei der TCP-Listener dabei nicht korrekt gelöscht und einkommende TCP-SYN Pakete werden nicht rejectet sondern der Listener versucht die gekillte Anwendung zu erreichen. Da diese aber nicht mehr existiert wartet der Listener ewig auf eine Antwort und schickt somit weder ein SYN-ACK noch ein RST zurück, was als halboffene Verbindung gezählt wird. Sobald die konfigurierte Grenze (100) überschritten wird, werden weitere Verbindungsversuche auf diesen Port geblockt - und zwar solange bis 30 Sekunden lang keine weitere Anfrage mehr kommt.
Beim normalen Beenden der Windowsversion, wird auch automatisch der Listener gelöscht (wenn du sie über den Taskmanager abschießt, dann dürfte das gleiche passieren, wie beim "kill"). Desweiteren meldet sich der Windowsclient beim korrekten Beenden offenbar auch wieder beim Indexserver ab, weshalb kaum noch Anfragen reinkommen.Da das Ganze bei Windows nicht auftritt (wir haben es unter Beobachtung des Router-Status ausprobiert, dort kommen nach Beendigung der Eselsoftware höchsten noch 10 oder 15 Anfragen, die ins leere laufen), muß es IMO am verwendeten mldonkey oder an den Router-Einstellungen liegen.
Versuch doch mal mldonkey auf korrekte Weise zu beenden - also nicht mit "kill". Dann sollte auch Ruhe sein...
was meinst Du mit im Betrieb "dichtmachen"? Wenn der mldonkey läuft, dann werden keine halboffenen Verbindungen erzeugt - auch nicht für Anfragen für gelöschte Files, da die TCP-Verbindung ja komplett aufgebaut werden muß, um diese Anfrage überhaupt stellen zu können...Außerdem ist mir dabei noch aufgefallen, daß dieser Counter den Router auch nach ca. 10 Std. Betrieb "dichtmachen" läßt, sprich dann sind so viele Anfragen aufgekommen, das nix mehr geht (in der Zwischenzeit habe ich bestimmte Files aus dem sharing gelöscht, vermutlich sind es Anfragen bzgl. dieser nicht vorhandenen files).
Gruß
Backslash
Hallo,
es liest also doch jemand mein Problem
Läßt sich das Verhalten evtl. durch eine (wieauchimmergeartete) zusätzliche iptables-Regel auf dem Debian-Rechner ändern? Eine Verhaltensänderung bei mldonkey ist mir momentan nicht bekannt. Leider.
Dirk
es liest also doch jemand mein Problem
Da habe ich aber keine Eingriffsmöglichkeit. Nach meiner bisherigen Erkenntnis ist ein kill unter Linux für den mldonkey die korrekte Beendigungsweise. Man kann ihn auch via HTML-GUI beenden, da gibt man aber auch nur "kill" bzw. "kill core" ein...backslash hat geschrieben:genau das dürfte dein Problem sein...Problem ist, daß, wenn ich den mldonkey "wie vorgesehen" via kill tasknummer beende, mein Router den Esel-Port dichtmacht. Nach einiger Beobachtung habe ich folgendes herausgefunden:
Offenbar wird dabei der TCP-Listener dabei nicht korrekt gelöscht und einkommende TCP-SYN Pakete werden nicht rejectet sondern der Listener versucht die gekillte Anwendung zu erreichen. Da diese aber nicht mehr existiert wartet der Listener ewig auf eine Antwort und schickt somit weder ein SYN-ACK noch ein RST zurück, was als halboffene Verbindung gezählt wird. Sobald die konfigurierte Grenze (100) überschritten wird, werden weitere Verbindungsversuche auf diesen Port geblockt - und zwar solange bis 30 Sekunden lang keine weitere Anfrage mehr kommt.
Läßt sich das Verhalten evtl. durch eine (wieauchimmergeartete) zusätzliche iptables-Regel auf dem Debian-Rechner ändern? Eine Verhaltensänderung bei mldonkey ist mir momentan nicht bekannt. Leider.
Hmm. Kannst Du das mal ausführlicher erläutern? Mit den Begriffen "listener" und "Indexserver" kann ich nicht wirklich viel anfangen. Ich habe das mit dem "listener" aus dem ersten Zitat oben nicht verstanden: läßt sich das Verhalten von mir bzw. durch den Router beeinflussen, oder liegt das an der Gegenseite und ich kann da nix machen?Beim normalen Beenden der Windowsversion, wird auch automatisch der Listener gelöscht (wenn du sie über den Taskmanager abschießt, dann dürfte das gleiche passieren, wie beim "kill"). Desweiteren meldet sich der Windowsclient beim korrekten Beenden offenbar auch wieder beim Indexserver ab, weshalb kaum noch Anfragen reinkommen.
Wie gesagt -soweit ich weiß *ist* das die korrekte Terminierungsart.Versuch doch mal mldonkey auf korrekte Weise zu beenden - also nicht mit "kill". Dann sollte auch Ruhe sein...
Momentan (der Rechner mit dem Esel läuft grad 1d10h15m, der Esel dürfte so ca. 4Std. weniger laufen, Zwangstrennung war um 0300 morgens, also besteht die Verbindung inkl. Esel jetzt 17Std.) habe ich laut Status 45 HO-Verbindungen. Ich habe im Laufe des Tages öfter mal reingeschaut, heute morgen so gegen 10 waren es ca. 20, der Wert steigt schwankend. Irgendwo müssen die ja herkommen...was meinst Du mit im Betrieb "dichtmachen"? Wenn der mldonkey läuft, dann werden keine halboffenen Verbindungen erzeugt - auch nicht für Anfragen für gelöschte Files, da die TCP-Verbindung ja komplett aufgebaut werden muß, um diese Anfrage überhaupt stellen zu können...Außerdem ist mir dabei noch aufgefallen, daß dieser Counter den Router auch nach ca. 10 Std. Betrieb "dichtmachen" läßt, sprich dann sind so viele Anfragen aufgekommen, das nix mehr geht (in der Zwischenzeit habe ich bestimmte Files aus dem sharing gelöscht, vermutlich sind es Anfragen bzgl. dieser nicht vorhandenen files).
Dirk
Hi Dirk,
Der Indexserver ist der Server auf dem deine IP-Adresse abgelegt wird während der Esel läuft, damit andere dich überhaupt finden können...
Gruß
Backlsash
mldonkey öffnet auf deinem Rechner einen Port und wartet darauf, daß irgendwer ihn kontaktiert. Dazu "installiert" er auf diesem Port einen Listener, der ihn informiert, wenn jemand auf diesem Port eine Verbindung aufbauen will. Wenn der Listener beim Beenden nicht wieder "deinstalliert" wird, dann bleibt der Port offen, nimmt aber keine Verbindungen mehr an bzw. lehnt die Anfragen auch nicht ab, weshalb sich daraufhin die halboffenen Verbindungen ansammeln.Hmm. Kannst Du das mal ausführlicher erläutern? Mit den Begriffen "listener" und "Indexserver" kann ich nicht wirklich viel anfangen. Ich habe das mit dem "listener" aus dem ersten Zitat oben nicht verstanden: läßt sich das Verhalten von mir bzw. durch den Router beeinflussen, oder liegt das an der Gegenseite und ich kann da nix machen?
Der Indexserver ist der Server auf dem deine IP-Adresse abgelegt wird während der Esel läuft, damit andere dich überhaupt finden können...
Da hast du dann vermutlich jede Menge Anfragen und du schaust halt auf eine Momentaufnahme - jede Verbindung ist erstmal halboffen, bis das dritte Paket (SYN -> SYN-ACK -> ACK) gelaufen ist. Versuch doch einfach mal die Schwelle etwas höher zu setzen - vielleicht hilft dasMomentan (der Rechner mit dem Esel läuft grad 1d10h15m, der Esel dürfte so ca. 4Std. weniger laufen, Zwangstrennung war um 0300 morgens, also besteht die Verbindung inkl. Esel jetzt 17Std.) habe ich laut Status 45 HO-Verbindungen. Ich habe im Laufe des Tages öfter mal reingeschaut, heute morgen so gegen 10 waren es ca. 20, der Wert steigt schwankend. Irgendwo müssen die ja herkommen...
Gruß
Backlsash