xDSL.at

hab seit 3 Jahren einen UMTS-Zugang von drei, und von Tag 1 an is mir aufgefallen, dass sich längere ssh-idle-sessions (=vergessen zu beenden, und nach 8h braucht mans dann doch wieder und is froh dass schon offen is ) wie vorher an DSL nicht stabil halten. Verbindungen bei denen "was los is" z.b. auch SFTP-übertragungen die auf 8kbit/s runtergeschraubt sind, werden nie abgewürgt und laufen in aller Regel durch.
Das ganze stört mich eigentlich auch nicht, macht man halt neu auf, mich würde nur interessieren, woran das liegt? ich denk mal das dürfte prinzipbedingt sein?

Kann auch der Server abwürgen, bei mir is nach maximal 2H idle auch Schluss. Am Netz liegt es nicht

ich hab meine freund bei 3 gefragt: er weiss es nicht. und fuer notebook anwerfen und ausprobieren, ist es ihm grad zu heiss. erinner uns ev. waehrend der naechsten schlechtwetterperiode dran

ich kann mich nur erinnern, dass meine ssh-verbindung vom buero nach hause frueher, als wir im buero noch ta adsl hatten, im laufe des tages mehrfach abgebrochen ist. (die internet-verbindung selbst hat, abgesehen vom 8-stunden-disconnect, tadellos gehalten.) seit wir einen anschluss von inode/upc haben, haelt sie bombenfest. obwohl das adsl technisch das gleiche ist. technisch habe ich keine erklaerung dafuer.

Als ich 2011 auf dieses Problem gestoßen bin, hat mir - wie nun bei medice - auch niemand gelaubt

Betrachtet man die ganze Realität, ist es so, dass bei Drei sämtliche Datenverbindungen durch eine Firewall mit stateful packet inspection laufen.

Datenpakete können nur zu bereits aktiven und bestehenden Verbindungen übetragen werden, "verwaiste" Pakete ohne Zugehörigkeit zu einer bestehenden TCP-Verbindung werden von der Firewall verworfen, ohne Rückmeldung an den Absender.

Weiters ist in der Drei-Firwall ist ein Timeout konfiguriert, das bei einer normalen TCP-Verbindung genau 10 Minuten nach dem zuletzt übetragenen Datenpaket zuschlägt und die Verbindung in der Firwall verwirft. In Folge existiert die Verbindung in der Firwall nicht mehr, und alle weiteren dazugehörigen Datenpakete kommen nicht mehr hindurch (egal von welcher Seite sie gesendet wurden). Die weiteren Pakete gehören dann ja nicht mehr zu einer bestehenden Verbindung.

Heißt kurz: Eine TCP-Verbindung stirbt nach 10 Minuten Inaktivität, weil sie aus der SPI-Firwall des Providers gedroppt wird.

Leider bemerkt man das nicht wenn es geschieht (zB mittels RESET-Paket oder was auch immer im IP-Protokoll dafür vorgesehen ist), sondern erst dann, wenn später wieder Datenpakete gesendet werden, diese dann aber nach einem Timeout nicht zugestellt werden können.

Für SSH ist es das Einfachste, TCP Keepalive zu aktivieren.
Ob am Client oder Server ist egal - sobald eine der Gegenstellen regelmäßig in Keepalive-Daten sendet, sind die Abbrüche Geschichte.

Alle 5 Minuten ein Paket reicht hier locker, bzw. genau genommen würde alle 9 Minuten und 59 Sekunden ein Paket reichen, denn gedroppt wird eine TCP-Connection in der Drei-Firewall exakt nach 10:00 Minuten.


2011 war es anfangs ja noch schlimmer bestellt um die restriktiven Prüfungen der Firewall.
Damals wurden eingehende TTL exceeded Pakete (hoffe die heißen so) nicht zugestellt, was ein Traceroute unmöglich machte.

Das hat sich aber geändert, und vergleicht man mit anderen Mobilfunkern die Möchtegern-ISP spielen und dabei nicht einmal eine öffentliche und/oder von außen erreichbare IP vergeben, ist man mit Drei immer noch sehr gut aufgestellt.

citr3x hat geschrieben:Kann auch der Server abwürgen, bei mir is nach maximal 2H idle auch Schluss. Am Netz liegt es nicht

es geht ja um den/dieselben Server, da hab ich nicht drauf hingewiesen


bzw keep-alive - i bin davon ausgegangen, dass das sowieso besteht, mal die settings beforschen...