packet_write_wait Pipe kaputt, auch wenn sie oben läuft?

26

Dieser blutige Fehler lässt meine Kopfschmerzen jeden Tag größer und größer werden. Ich habe nie die gleiche Situation getroffen wie diesmal.

Nun, nachdem ich mich erfolgreich bei SSH authentifiziert habe und ein paar Dinge erledigt habe, wurde meine SSH-Verbindung plötzlich getrennt !!?

Hier ist meine Fehlermeldung: packet_write_wait: Connection to XXX.XX.XX.XXX: Broken pipe

Ich wünschte, meine Fehlermeldung würde so aussehen: Write Failed: broken pipeviel, glaub mir!

Ich habe eine Menge Auflösungen im Internet ausprobiert, wie etwa ServerAliveInterval, ServerAliveCountMax, ClientAlive ...

Jemand sagte: Schalten Sie Ihr TCPKeepAlive auf Nein, fügte ServerAlive hinzu, bllah blah Idiot. Ich habe das auch gemacht aber immer noch den gleichen Fehler.

Bis zu diesem Moment habe ich kein Glück.

Jede Hilfe wird geschätzt.

ssh

— Toan Nguyen
quelle

2

Wenn Sie sich in einer Unternehmensumgebung befinden, erkundigen Sie sich bei Ihren Firewall-Administratoren, ob diese nach einer Änderung die Regeln aktualisieren und / oder die Firewall neu starten. Wenn es sich um einen Personal Server handelt, müssen Sie weitere Informationen darüber bereitstellen, was Sie auf der SSHD-Serverseite getan haben, als dies passierte. Broken pipeIm Allgemeinen bedeutet dies, dass aus irgendeinem Grund eine Netzwerkverbindung unterbrochen wurde.

— MelBurslan

Ich bin gerade umgezogen und das passiert ständig mit meiner neuen Verbindung. Cox Cable ist mein ISP, und ich habe ein Netgear C6300BD-Kabelmodem, das bei der Installation mit den Standardeinstellungen ausgeführt wird. Dies geschah früher an meinem alten Standort und ich konnte es nie lösen. Es dauerte Monate und hörte schließlich auf zu geschehen. Ich habe vergessen, wie miserabel und unlösbar es bis heute war.

— T. Brian Jones

Ich fühle deinen Schmerz. Ich bin als letzter Ausweg hierher gekommen, bevor ich meine gesamte Hardware in winzige kleine Stücke zerschlagen werde. Soll das nicht ein ziemlich einfaches Protokoll sein?

— DerpyNerd

Ich hatte den gleichen Fehler unter Virtualized Linux, das Problem wurde durch Ändern des Ethernet-Adapters auf Bridged behoben

— Abel Barrios

8

Liebe Leser von 2018 und später,

Lassen Sie mich Ihnen einen Kommentar von MelBurslan zeigen,

Wenn Sie sich in einer Unternehmensumgebung befinden, erkundigen Sie sich bei Ihren Firewall-Administratoren, ob diese nach einer Änderung die Regeln aktualisieren und / oder die Firewall neu starten. Wenn es sich um einen Personal Server handelt, müssen Sie weitere Informationen darüber bereitstellen, was Sie auf der SSHD-Serverseite getan haben, als dies passierte. Ein Leitungsbruch bedeutet im Allgemeinen, dass aus irgendeinem Grund eine Netzwerkunterbrechung aufgetreten ist.

Im Grunde genommen also, wenn Sie versuchen, ssh username@0.0.0.0über ein VPN (Unternehmensumgebung) zu verwenden. Dann muss dieser Fehler immer und immer wieder bei Ihnen sein.

Die einzige Lösung, die ich bisher gefunden habe, ist mobile-shell . Vielen Dank, wer es erstellt hat.

Sie müssen auf mosh-serverIhrem Zielsystem (dem Server, auf den Sie senden möchten) und mosh-clientauf Ihrem Hostcomputer installiert sein .

Es wird sich automatisch wieder verbinden, wenn Ihre Pakete verloren gehen, das ist ziemlich cool und entspricht all unseren Bedürfnissen, denke ich.

Viel Spaß beim Stöbern!

— Toan Nguyen
quelle

3

Ich habe festgestellt, dass es sich bei meinem VMware Guest-Setup um ein Problem mit der IPQoS-Option handelt. Auf der VM habe ich den ~ / .ssh / config-Wert für IPQoS festgelegt. Der Standardwert für "IPQoS af21 cs1" ist Daten mit niedriger Latenz für interaktive erste und geringerer Aufwand für nicht interaktive zweite. Einen neuen Wert für af21 zu setzen, war meine Lösung:

Host *
     IPQoS throughput

Hat bei mir funktioniert, ansonsten funktioniert ja auch MoSH, aber mosh behandelt mein Proxy-Setup nicht auf bequeme Weise, so dass ich bei ProxyJump-Befehlen bleibe

— Rupert160
quelle

Spaß, das funktioniert in der Kommandozeile (wie Sie in Ihrem Beitrag auf Ubuntu erklären), aber nicht in der Konfigurationsdatei 8-D

— Aurelien

1

Stellen Sie zunächst sicher, dass Ihr Problem nicht mit diesem zusammenhängt .

Wenn nicht und das Problem weiterhin besteht, lesen Sie weiter.

Ich habe dieses Problem auch erlebt und ein paar Tage lang versucht, es zu zerfetzen.

Wie angegeben, löst das Spielen mit SSH-KeepAlive-Parametern oder Kernel-TCP-Parametern (TCPKeepAlive ein / aus) das Problem nicht.

Nachdem ich mit USB zu Ethernet-Treibern und TCP-Dump gespielt hatte, wurde mir klar, dass das Problem am Kernel 4.8 lag. Ich habe die Quelle (senderseitig) auf 4.4 LTS umgestellt und das Problem ist verschwunden (rsync, scp funktionierte wieder einwandfrei). Die Zielseite kann auf 4.8 bleiben, wenn Sie möchten, in meinem Anwendungsfall hat dies funktioniert (getestet).

Auf der technischen Seite können wir das Problem ein wenig eingrenzen, dank des Wireshark-Dumps, den ich unten erstellt habe. Wir können sehen, dass der TCP-Kanal des SSHv2-Protokolls zurückgesetzt wird (RST-Flag von TCP auf 1 gesetzt), wodurch die Verbindung abgebrochen wird. Ich kenne die Ursache des RST noch nicht. Ich muss dafür eine Halbierung von 4.8.1 bis 4.8.11 vornehmen.

Ich sage nicht, dass Ihr Problem speziell auf den Kernel 4.8 zurückzuführen ist, aber wrt. Am Tag, an dem Sie Ihre Frage / Nachricht gepostet haben, haben Sie möglicherweise eine Kernel-Version verwendet, die tatsächlich fehlerhaft war.

Zunächst auf StackOverflow beantwortet .

— wget
quelle

Kernel ist nicht das Problem, weil ich die ganze Zeit 4.4 LTS verwendet habe. Das eigentliche Problem hier wurde von @ MelBursan im Kommentar der Frage beantwortet. Meine Internetverbindung über VPN, deshalb. Lösung: mosh.org

— Toan Nguyen

@ ToanNguyen Ok. Könnten Sie auf diese Weise bitte seinen Kommentar als Antwort auf Ihre Frage einfügen und ihn als behoben markieren? :-) Wenn Sie die technischen Gründe gefunden haben, warum Sie mosh brauchten, fügen Sie sie bitte auch hinzu :-). Auf meiner Seite habe ich auch VPN-Verbindungen und diese funktionierten einwandfrei ohne Mosh.

— Wget

Ich komme darauf zurück. Das Problem lag nicht an einem fehlerhaften Kernel, sondern an einem fehlerhaften Treiber, insbesondere an dem Teil, der für das Abladen der Hardware-Prüfsumme vorgesehen war. In diesem Thread finden Sie weitere Informationen .

— Wget

Löst es dein Problem?

— Toan Nguyen

@ ToanNguyen Als ich das letzte Mal dieses Problem hatte, habe ich einfach den Kernel heruntergestuft und es funktionierte wieder. Jetzt habe ich einfach das hw-Prüfsummen-Offload deaktiviert, ohne etwas herabzustufen, und das Problem wurde behoben, ja.

— wget

1

ssh -o IPQoS=throughput user@{ip}

— Vicky Penkova
quelle

Es gibt keinen Hinweis darauf, dass der Benutzer macOS verwendet oder versucht, sich als root anzumelden.

— Kusalananda

Du hast recht! Ich habe den Befehl jedoch mit einem anderen Benutzer als 'root' und unter Windows getestet. Funktioniert noch!

— Vicky Penkova

0

Öffnen Sie die Datei ssh.config auf dem Zielserver mit dem folgenden Befehl:

sudo nano /etc/ssh/ssh.config

Fügen Sie die folgenden Zeilen am Ende dieser Datei hinzu

ClientAliveInterval 300

ClientAliveCountMax 2

Drücken Sie Strg + o und geben Sie ein.

sudo neu starten

Das hat bei mir sehr gut funktioniert. Ich war in der gleichen Situation. Versuchte dies und das, aber folge einfach diesen Schritten. Nur das. Ich hoffe, es wird auch für Sie funktionieren.

— DonFeraRRi
quelle