Beiträge von taskmanager

taskmanager · 30. November 2014

Auf Rückfrage beim AVM-Support bekam ich die Antwort, dass der Bug in der kommenden Firmware behoben ist.
Der Fix ist angeblich auch in der aktuellen Beta enthalten:

Zitat

vielen Dank für Ihre Rückmeldung und Ihre Geduld.

Bis ein neues FRITZ!OS-Update zur Verfügung steht, können Sie eine
Beta-Version installieren, in der dieser Fehler bereits behoben ist:

1. Rufen Sie im Internetbrowser (z.B. Firefox, Internet Explorer,
Safari) die Adresse ftp://service.avm.de auf und wechseln Sie in den Ordner
"Beta" und dann in den Unterordner für Ihr FRITZ!Box-Modell.
2. Laden Sie die Beta-Version für Ihr FRITZ!Box-Modell auf den Computer
herunter.
3. Entpacken Sie die ZIP-Datei auf Ihrem Computer (z.B. auf dem
Desktop).
4. Installieren Sie die Beta-Version (Image-Datei) für Ihre FRITZ!Box
wie in der infobeta.txt beschrieben.

Alles anzeigen

Ich habe die Firmware nicht ausprobiert. AVM gibt zu Problemen mit Beta-Firmware keinen Support und keine Garantie. Mein Router ist ja kein brickbares Testgerät.

Daher ist die FritzBox zum Modem degradiert. Das Netzwerk organisiert mein altehrwürdiger Linksys WRT54GL.

taskmanager · 14. Oktober 2014

Es könnte ein Fehler in der aktuellen Firmware der FritzBox sein:

Zitat

Nach Installation von FRITZ!OS 6.20 können an einem mit der FRITZ!Box verbundenen WLAN-Gerät bestimmte Internetanwendungen (z.B. Twitter-Streams, SSH-Verbindungen) nicht mehr oder nur noch sehr langsam auf das Internet zugreifen.

taskmanager · 6. Oktober 2014

Um ein paar Logmeldungen zu bekommen, habe ich nun den Loglevel des SSH-Servers auf DEBUG3 erhöht und durchgestartet.

Im Terminal habe ich die Ausgabe mittels tail -f /var/log/auth.log beobachtet:

Code

19:43:19 hostname: debug2: channel 0: rcvd adjust 49888
19:43:23 hostname: debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1
19:43:29 hostname: message repeated 2 times: [ debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1]
19:43:31 hostname: debug2: channel 0: rcvd adjust 49174
19:43:35 hostname: debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1
19:43:59 hostname: message repeated 9 times: [ debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1]
19:43:59 hostname: debug2: channel 0: rcvd adjust 49572
19:44:01 hostname: debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1
19:44:21 hostname: message repeated 10 times: [ debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1]
19:44:27 hostname: debug2: channel 0: rcvd adjust 49339
19:44:32 hostname: debug2: channel 0: rcvd adjust 50038
19:44:35 hostname: debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1
19:45:13 hostname: message repeated 18 times: [ debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1]
19:45:13 hostname: debug2: channel 0: rcvd adjust 49159
19:45:15 hostname: debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1
19:45:57 hostname: message repeated 21 times: [ debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1]
19:45:57 hostname: debug2: channel 0: rcvd adjust 49316
19:45:59 hostname: debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1 <-- Sitzung friert ein, letzte Zeile im Log




Terminal trennt sich mit: Timeout, server hostname not responding.
Weiterer Inhalt des Logs nach Wiederanmelden:




19:46:23 hostname: message repeated 13 times: [ debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1]
19:46:23 hostname: Connection closed by <IP>

Alles anzeigen

Beim zweiten Einfrieren zeigt sich ein ähnliches Bild:

Code

19:48:20 hostname: message repeated 22 times: [ debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1]
19:48:21 hostname: debug2: channel 0: rcvd adjust 49765
19:48:22 hostname: debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1
19:48:56 hostname: message repeated 17 times: [ debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1]
19:48:59 hostname: debug2: channel 0: rcvd adjust 50099  <-- Sitzung friert ein, letzte Zeile im Log




Terminal trennt sich mit: Timeout, server hostname not responding.
Weiterer Inhalt des Logs nach Wiederanmelden:




19:49:04 hostname: debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1
19:49:04 hostname: message repeated 2 times: [ debug1: server_input_global_request: rtype keepalive@openssh.com want_reply 1]
19:49:04 hostname: Connection closed by <IP>
19:49:04 hostname: debug1: channel 0: free: server-session, nchannels 1

Alles anzeigen

taskmanager · 4. Oktober 2014

Wenn ich die Sitzung mit einem AliveInterval von 1 starte:

Code

ssh -o ServerAliveInterval=1 netcupserver

erhalte ich nach kurzer Zeit vom Server

Code

Timeout, server netcupserver not responding.

Das würde bedeuten, dass der Client von Server 3 Sekunden lang keine Antwort bekommt?

(Drei Sekunden weil ServerAliveCountMax im default drei ist)

taskmanager · 4. Oktober 2014

Hallo,

ich habe seit kurzen das Problem, dass meine SSH-Verbindungen zu meinem vServer plötzlich einfrieren bzw. sehr sehr langsam werden.

Auch dem Server läuft Ubuntu 14.04 und als Screenfrontend Byobu. Byobu zeigt rechts unten eine Uhr an.
Wenn die Verbindung schlechter wird, aktualisiert sich auch die Uhr nicht mehr.
Befehle aus dem Terminal werden entgegen genommen, aber die Ausgabe wird nicht mehr dargestellt. Erst nach einem neuen Login, kann ich die Ausgaben sehen.

Im lokalen Netz steht ein Server mit einer ähnlichen Konfiguration. Bei diesem treten die Verbindungsprobleme nicht auf. Ich finde aber nicht den Unterschied zwischen beiden.

Hat wer ein ähnliches Problem gelöst, oder weiß wo ich noch suchen könnte?

Beste Grüße
taskmanager

Beiträge von taskmanager

SSH-Verbindung friert ein

SSH-Verbindung friert ein

SSH-Verbindung friert ein

SSH-Verbindung friert ein

SSH-Verbindung friert ein