Unitymedia SSH Verbindungsabbrüche

[Schnee]

Hallo liebe Gemeinde,

benötige euren Rat / Erfahrung.
ich habe seit einigen Wochen sowohl privat, als auch geschäftlich einen Anschluss bei Unitymedia bekommen. 1 x 125 MB geschäftlich und 1 x 32 MB privat an unterschiedlichen Standorten.
Für beide Anschlüsse wird die Fritzbox "FRITZ!Box Fon WLAN 6360" verwendet. Mit beiden Anschlüssen gibt es massive Probleme bei der Aufrechterhaltung
einer Terminalverbindung per SSH (z.B über putty) Jede SSH-Konsole friert sporadisch nach einer gewissen Zeit ein. Manchmal nach 1 Minute, manchmal nach 5 Minuten. Man muss das Terminal hart beenden und neu verbinden. Die Internetverbindung generell bleibt aber bestehen. (Ein ping auf eine beliebige Webseite zeigt keine Paketverluste). Da es sich um zwei unabhängige Standorte handelt und die einzige Gemeinsamkeit (abgesehen vom Anbieter) die FritzBOX ist, vermute ich, daß da der Fehler liegen könnte. Der Support von Unitymedia scheint bemüht, macht updates, fragt nach - es nützt aber nichts. Hat jemand von euch ähnliche Erfahrungen oder sogar einen Tipp wie man das beheben kann? Danke im Voraus und schönen Sonntag noch.

 

[piotr]

Lass es alternativ mal mit einem normalen UM Produkt und einem anderen Router testen, um die FB6360 ausschliessen zu koennen.

Beim normalen 1 oder 3 play 32000 und 128000 bekommst Du keine 6360, sondern das separate Kabelmodem Cisco EPC3212.
Ggfl. laesst Du Dir bis zu 2 der 3 Nummern auf das EPC-Modem schalten um das laenger testen zu koennen und auch noch (mit analogen Leitungen) telefonisch erreichbar zu sein.

Der Link ist zwar fuer ein anderes FB-Modell, kann aber sinngemaess auch hier helfen:
http://wilfing.eu/artikel/ssh-keepalive

Ansonsten halt die ueblichen Fragen:
Ging es denn vor der Schaltung des UM-Anschlusses ?
Ist das nur ssh, was immer wieder geschlossen wird oder betrifft das zur selben Zeit auch andere TCP-Verbindungen mit aehnlicher Verwendung z.B. telnet, rdp, vnc, scp, sftp ...?
Welche SSH Version?

 

[Schnee]

Hallo piotr,

vielen Dank für deine prompte Antwort. Der Techniker von der beauftragten Firma hat, nachdem er die FritzBOX ausgetauscht hat (gegen ein Baugleiches Modell) gemeint: Es gäbe noch eine andere Möglichkeit über ein Cisco-Modem. Da es sich aber um einen Geschäftskundenanschluß handelt, geht das nicht (dieses ist nur für privat Anschlüsse verfügbar). Bei mir daheim handelt es sich um einen Kombianschluß mit ISDN-Merkmalen, daher habe ich auch dieselbe FritzBOX bekommen wie im Geschäft.

>>Ging es denn vor der Schaltung des UM-Anschlusses ?
Ja,es geht auch mit jeder anderen beliebigen Leitung.

>>betrifft das zur selben Zeit auch andere TCP-Verbindungen mit aehnlicher Verwendung z.B. telnet, rdp, vnc, scp, sftp ...?
zur zeit weiss ich es nur von SSH.

SSH Version ist >2. Port 22

Das ist supernervig, zumal ich weitere Dienste wie VNC über SSH-Tunnel nutze, diese Verbindungen brechen dann natürlich auch ab.

 

[Schnee]

Lass es alternativ mal mit einem normalen UM Produkt und einem anderen Router testen, um die FB6360 ausschliessen zu koennen.
Der Link ist zwar fuer ein anderes FB-Modell, kann aber sinngemaess auch hier helfen:
http://wilfing.eu/artikel/ssh-keepalive
?

Die Abbrüche haben mit einem normalen Verbindungstimeout nichts gemein. Auch aktive Terminals "sterben" innerhalb kurzer Zeit :-(

 

[piotr]

Wie war die Verbindung an anderen, funktionierenden Anschluessen?
Auch ueber Fritzboxen?

Im Netz findet man viele Treffer zu ssh timeouts mit verschiedenen Fritzbox-Modellen, wo es vorher ohne Fritzbox ging.
Allesamt zeigen auf die tcp keepalives, welches a) aktiviert sein und b) deren Interval herabgesetzt werden muss.

 

[Schnee]

Funktioniert hat es bisher über ADSL Leitungen in Verbindung mit Telekom-Routern.
OK, ich versuche es mal indem ich den keepalive-intervall auf meinem lokalen PC auf 10 sekunden stelle und melde mich später ob es einen Effekt hatte.
Danke dir derweil

 

[piotr]

Welche Telekomrouter genau?

Etliche Speedport-Modelle sind von AVM, z.B. W701V, W722V Typ A, W900V, W920V.

Sie sind Fritzbox-Modellen (W701V -> 7170, W722V Typ A -> 7270v3, W900V -> 7270, W920V -> 7570) aehnlich und koennen - mit einer per speed2fritz angepassten Firmware- neben dem TDSL- auch am UM-Anschluss (hinter einem separaten Kabelmodem) laufen.

 

[Schnee]

mit der W701V hat es zuletzt funktioniert.

Also bisher lebt meine neue SSH-Session mit 10 Sek Keepalive - Timeout noch
Wenn das die Lösung ist, bin ich schonmal glücklich. Ist zwar etwas "uncool" aber Hauptsache gelöst.
Ich könnte den alten WLAN Router sicherlich verwenden, aber wie du schon gesagt hast, dann müsste ein extra Kabelmodem her. Ich würde das jetzt mal als Notlösung betrachten.
Am besten wäre natürlich ein Firmwareupgrade für die FB welches dieses Problem löst. Vielleicht reagieren Sie darauf erst wenn eine gewisse Menge an anfragen diesbezüglich kommt?

 

[piotr]

Der Speedport W701V wuerde auch nicht am 128000er und auch nicht am 32000er Anschluss laufen.

Der Speedport W701V ist eine um ein 3 Anschluesse kastrierte Fritzbox 7170; es fehlen der USB- der interne S0 sowie der Klemmenanschluss fuer Fon3.

Die 7170 kann nur max 24000 ... deshalb gibt UM ja auch die 6360 bereits bei 32000 (zumindest auf Anfrage) raus.

 

[Schnee]

also meine SSH-verbindung besteht jetzt etwas mehr als 1 Stunde. Ich würde sagen: das ist neuer Rekord und würde mal vorsichtig behaupten, daß das die Lösung des Problems ist. Ein Bug ist es allemal, denn ein Timeout-Signal nach ein paar Sekunden zu generieren kann nihct gewollte sein. Ich werde das morgen an mehreren PCs mit der neuen Einstellung testen und mich dann nochmal melden. Danke Dir Piotr für den entscheidenden Hinweis. LG

 

[piotr]

Ein sehr kleines idle-timeout stammt vermutlich noch aus den Zeiten, wo Router im Consumerbereich aus Kostengruenden nur eine sehr bescheidene Routing-Performance und auch nur sehr wenig RAM hatten.

Router im Consumerbereich haben idR NAT (genauer: Source NAT) und eine Stateful Packet Inspection Firewall.

D.h. es muessen hier (in mehreren Tabellen) im RAM immer die Verbindungen der einzelnen LAN-IPs zur lokalen Router-IP, die dazugehoerigen Verbindungen der WAN-Router-IP zum jeweiligen Ziel, die Rueckantworten des Ziels zur WAN-IP des Routers sowie auch die dazugehoerigen Verbindungen der lokalen Router-IP zu den LAN-IPs gespeichert und zugeordnet werden koennen.

Damit das nicht zuviel Last auf einem Router erzeugt, wird die TCP-Verbindung nach einer in der Router-Firmware eingestellten idle-Timeout getrennt und damit (die aus Sicht des Routers inaktive Verbindung) aus dem RAM entfernt.

 

[Micha2k]

Problem verwandt?
http://www.unitymediaforum.de/viewtopic.php?f=53&t=13109

Geht die Verbindung auch verloren, wenn der PC über WLAN mit der FB verbunden ist?

 

[Schnee]

[gelöst] SSH Verbindungsabbrüche

<r>Hallo,<br/>
<br/>
also ich kann jetzt nach 2 Tagen "Dauertest" behaupten, daß das Problem mit Senden eines TCP/IP Keep-Alive Signals alle 5-10 Sekunden behoben ist. Fehlerhaft scheint hier wirklich die Software der BOX zu sein, die Verbindungen trennt, weil sie sie fälschlicherweise viel zu früh für inaktiv hält. Bei Putty kann man im Menü "Connection" [x] Keep alive Signal senden ; Intervall: 5 Sekunden einstellen. Für Linuxrechner ist die Anleitung hier:<br/>
<br/>
<URL url="http://wilfing.eu/artikel/ssh-keepalive">http://wilfing.eu/artikel/ssh-keepalive</URL><br/>
<br/>
Vermutlich gibt es da parallelen zu Verbindungsabbrüchen bei Teamspeak-Servern. <br/>
<br/>
viele Grüße & Danke</r>

 

[Rjinswand]

Hallo,

auch wenn das hier ein sehr alter Thread ist, passen die Aussagen nicht zu den Beobachtungen, die ich hier machen konnte. Ich hab dasselbe Problem, dass IPv4-TCP-Verbindungen schon nach recht kurzer Zeit sterben (RST-Pakete kommen zurück, falls man doch noch neuen Traffic erzeugt).

Es liegt nicht an der Fritz!Box. Zum einen hat die Fritz!Box einen Idle-Timeout für die TCP-NAT-Verbindungen von 15 Minuten (http://avm.de/nc/service/fritzbox/f...h-die-Verbindung-zu-Gegenstellen-im-Internet/), zum anderen kann ich sehen, dass die Verbindung aus FritzBox-Sicht noch aktiv ist (Mit der Fritzbox kann man auch die Internetseite gut mitsniffen, und das sah noch ganz gut aus).

Da ich auch ausschließen kann, dass die Server-Seite die Verbindung schließt, muss es irgendwo dazwischen sein. Meine Vermutung ist, dass das Carrier Grade NAT von Unitymedia hier diesen übermäßig kurzen Timeout hat und Verbindungen schon nach unter 2 Minuten idle killt.

Meine Störungsmeldung dazu wurde mit Textbausteinen beantwortet und beinhaltet die Bitte, mich dort telefonisch zu melden. Wenn ich mal etwas Ruhe habe, werde ich mich mal mit denen da auseinandersetzen, obwohl ich die Vermutung habe, dass ich auch da nicht wirklich verstanden werde

Naja, insgesamt kann man hier wieder sehen, wie krank das CGN eigentlich ist, und man hier kein "richtiges" Internet bekommt. Aber mit IPv6 wird alles besser. Das ist wirklich nativ unterstützt und funktioniert einwandfrei.

Grüße
Rjinswand