[Frage] häufiger Abbruch langlaufender TCP-Verbindungen

koronth

Neuer User
Mitglied seit
21 Nov 2008
Beiträge
68
Punkte für Reaktionen
1
Punkte
8
Hallo *,

ich habe 1&1 DSL250 am Berliner Stadtrand. Bis vor kurzem war ich anscheinend - seit Schaltung des Anschlusses - auf ein 175er DSL Profil geschaltet. Dann wurden technische Verbesserungen angekündigt und seitdem habe ich die volle DSL250 Geschwindigkeit anliegen.
Ich hänge am Versatel Backbone.

Aber das Problem, das ich schildere, habe ich von Anfang an; seitdem mein DSL Anschluss bei 1&1 geschaltet wurde.

Ich arbeite mit Terminalsitzung (x2go) über SSH sowie SSH-Transfers ins Deutsche Forschungsnetz (DFN).
Sowie die Terminalsitzungen als auch die SSH-Transfers erleiden in unregelmäßigen Abständen Verbindungsabbrüche.
Wenn ich paranoid wäre, würde ich sagen, sie bekommen ein administratives TCP Reset-Paket (von 1&1 ?) auf die Nase. ;-)
Denn die DSL Verbindung steht derweil wie eine Eins, und die (so schnell wie halt möglich) Versuche die Ziele im DFN wieder zu erreichen funktionieren auch tadellos.

Ich hätte diesen durchaus ärgerlichen Umstand vielleicht noch hingenommen, wenn ich mir nicht zufällig zwei weitere Uplinks (Kabelinternet & LTE Homespot) geleistet hätte, die dieses Phänomen nicht zeigen. Aber dafür dummerweise unter schlechterem Peering (ins DFN) leiden: :-(

Hingegen - vielfach erprobt - bei Benutzung des Kabelinternets bestehen die TCP-Verbindungen ins DFN völlig ungestört wochenlang. Wirklich wochenlang und nicht bloß 24h, da das Kabelinternet auch keine Zwansgtrennung hat; am Rande erwähnt.

Daher hier meine Frage: Gibt es hier jemanden mit einem ähnlichen Anwendungsszenario, der dieses Verbindungsabruchs-Problem kennt?

Danke & Bye!
 
Hallo @koronth ,
sieht man in den Systemmeldungen deines Routers eine Trennung der Internetverbindung?
 
Siehst Du das in Wireshark, lokal auf dem Computer? Wie lange ist die TCP-Verbindung idle, also wirklich idle? Eine FRITZ!Box macht nach 15 Minuten TCP-Verbindungen einfach zu. Mehr dazu in diesem Thread … Außer man tauscht ab und zu etwas aus. Auch TCP-Keep-Alive reicht. Auch reicht aus, wenn die Gegenseite etwas schickt. Hast Du Dein Computer-weites TCP-Keep-Alive zum Test bereits auf 15 Minuten herunter gestellt?

Wenn Du wirklich Idle brauchst, holst Du Dir idealerweise einen DSL-Router bei dem man dieses NAT- bzw. Firewall-Binding einstellen kann, also Lancom oder DrayTek. Musst für den Test ja kein Super-Vectoring fähiger DSL-Router sein. Welche mit VDSL100 gibt es bereits für unter 50€ gebraucht in eBay bzw. eBay-Kleinanzeigen, z.B. Lancom oder DrayTek Vigor mit „V“ in der Modell-Bezeichnung, also Lancom 1784VA oder DrayTek Vigor2760Vn Delight.
Gibt es hier jemanden mit einem ähnlichen Anwendungsszenario, der dieses Verbindungsabruchs-Problem kennt?
Ich hatte das vor über einem Jahrzehnt, mit 1&1 in alle Netze. Hat über ein Jahr gedauert, bis 1&1 es zugab und reparierte. Wenn es bei Dir nur DFN ist, würde ich in deren Community fragen, also in Mailing-Listen. Vielleicht kann das jemand testen. Muss aber kein allgemeiner Fehler sein. Bei mir schrieb 1&1 damals, dass es nur ganz wenige Kunden betroffen hatte.
 
Zuletzt bearbeitet:
Das ist ein bekanntes Problem bei SSH Sitzungen, das Internet ist voll davon. Es wird beeinflusst von den Routern auf dem Weg zwischen Server und Client, häufig spielen Connection Tracking oder NAT Timeouts eine Rolle.

Sowohl auf Server als auch auf Client Seite kann man ein Keepalive konfigurieren, damit ist das Problem weg (es reicht eine Seite). Alles andere ist ein Kampf gegen Windmühlenflügel.
 
  • Like
Reaktionen: chrsto
Vielen Dank für Eure Tips mit keep-alive etc. Aber das kann IMHO nicht des Pudels Kern sein, da auch meine laufenden Transfers über SSH abgebrochen werden.
Im übrigen - zur Erinnerung - habe ich die identische Konfiguration über Wochen über das Kabelinternet zu laufen. Das einzige was sich dann nach meinem internen Gateway offensichtlich unterscheidet, ist die externe Route zum Ziel und die benutzte Fritzbox (DSL, Kabel, LTE).


Ich hatte das vor über einem Jahrzehnt, mit 1&1 in alle Netze. Hat über ein Jahr gedauert, bis 1&1 es zugab und reparierte. Wenn es bei Dir nur DFN ist, würde ich in deren Community fragen, also in Mailing-Listen. Vielleicht kann das jemand testen. Muss aber kein allgemeiner Fehler sein. Bei mir schrieb 1&1 damals, dass es nur ganz wenige Kunden betroffen hatte.

Das ist ja interessant! Wie und was zum Henker hast Du denn damals 1&1 vorgetragen, bewiesen, ... ?

Ich habe (bisher) keinen Paketmitschnitt gemacht. Bisher wollte ich bloß arbeiten und wunderte und ärgerte mich über Verbindungsabbrüche. Soweit, irgendjemand etwas nachweisen zu wollen, war ich noch nicht.

Ich behaupte nicht, daß dieses Problem nur ins DFN auftreten würde. Aber nur ins DFN habe ich überhaupt stundenlange SSH-Sitzungen (wegen HomeOffice).
Bei der 0815-Nutzung des Internets (http etc.) würde das Problem sicherlich gar nicht auffallen/auftreten.
Andererseits beschwert sich aber auch meine Frau, die deutlich länger telefoniert als ich, über sporadische und unerklärliche Abbrüche ihrer Telefonverbindungen (die bei mir derzeit immer über die DSL-Verbindung gehen).
Vielleicht ist es ja an der Zeit, das im Zusammenhang zu sehen.?
 
Andererseits beschwert sich aber auch meine Frau, die deutlich länger telefoniert als ich, über sporadische und unerklärliche Abbrüche ihrer Telefonverbindungen
Dann lass sie doch mal probeweise über UDP telefonieren. Da sollte sie doch ziemlich schnell einen Unterschied feststellen, wenn da deiner Meinung nach ein Zusammenhang besteht.
 
Im übrigen - zur Erinnerung - habe ich die identische Konfiguration über Wochen über das Kabelinternet zu laufen.
Das war aber ein anderer Provider. Bei mir trat das Problem auch erst nach dem Wechsel Auf Glasfaser auf.

Probiere es mit der Keep Alive Einstellung. Wenn das nicht hilft, sehen wir weiter.
 
Wie und was zum Henker hast Du denn damals 1&1 vorgetragen[?]
Ich habe es 1&1 einfach geschildert. Ging damals um IMAP-IDLE. Und jede Ausrede die kam, konnte ich entkräften. Allerdings bezog sich mein Problem damals allein auf TCP-Verbindungen im IDLE. Wenn Du das Problem auch während einer laufenden Verbindung hast, also kurz vorher und in beide Richtungen über diese Verbindung übertragen hast, dann kannst Du meine Antworten ausblenden, weil bei Dir nicht zutreffend. Auch weil SSH – soweit ich es verstehe – keine separaten Kanäle nutze, wie zum Beispiel FTP für Data und Control.
Ich behaupte nicht, daß dieses Problem nur ins DFN auftreten würde.
Trotzdem, hau auch mal die DFN-Community an. Vielleicht erreichst Du so jemanden ebenfalls in Berlin mit 1&1, der das mal testen bzw. bestätigen kann. Vielleicht ist ein Übergangsknoten in Eurer Region kaputt oder falsch konfiguriert.
sporadische und unerklärliche Abbrüche ihrer Telefonverbindungen
VoIP/SIP geht normalerweise über UDP. Selbst wenn Du verschlüsselst telefonieren solltest, also über TLS und damit TCP, greift das nur während einem Telefonat, wenn „SIP Session Timers“ aktiv wären bzw. der Telefonie-Anbieter über ein SIP-INVITE bzw. SIP-UPDATE, ob Ihr noch da seit. Das kannst Du alles ausschließen, indem Du in der FRITZ!Box unter „Telefonie → Eigene Rufnummern → (Taste) Bearbeiten → Telefonie-Anbieter: Anderer Anbieter → (Taste) Weitere Einstellungen → Transportprotokoll“ auf UDP umstellst. Aber vermutlich greift eher die Lang-Quassel-Sperren des Netzbetreibers gegenüber. Manche kappen immer nach 30, manche nach zwei Stunden.

Also mein Vermutung und Tipp: TCP-Keep-Alive wird nicht helfen. Lasse Wireshark mitlaufen, filtere auf den TCP-Port und schaue, was kommt. Vermutlich kommt gar nichts, die Verbindung ist einfach abgerissen. → bei 1&1 melden.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.