packet_write_wait Złamana rura nawet pozostawia działającą górę?


26

Ten cholerny błąd sprawia, że ​​mój ból głowy rośnie z każdym dniem. Nigdy nie spotkałem takiej sytuacji jak teraz.

Cóż, po pomyślnym uwierzytelnieniu się w SSH i zrobieniu kilku rzeczy, nagle moje połączenie SSH zostało nagle przerwane !!?

Oto mój komunikat o błędzie: packet_write_wait: Connection to XXX.XX.XX.XXX: Broken pipe

Chciałbym, aby mój komunikat o błędzie wyglądał tak: Write Failed: broken pipebardzo, uwierz mi!

Próbowałem ton rozdzielczości w Internecie, takich jak ServerAliveInterval, ServerAliveCountMax, ClientAlive ....

Ktoś powiedział: Przełącz TCPKeepAlive na „nie”, dodał idiota ServerAlive bllah blah. Zrobiłem to również, ale wciąż ten sam błąd.

Do tego momentu nie mam szczęścia.

Każda pomoc będzie mile widziana.


2
Jeśli jesteś w środowisku korporacyjnym, skontaktuj się z administratorami zapory i sprawdź, czy aktualizowali reguły i / lub ponownie uruchamiali zaporę po jakiejś zmianie, gdy to nastąpi. Jeśli dzieje się to na twoim osobistym serwerze, musisz podać więcej informacji o tym, co robiłeś po stronie serwera sshd, kiedy to się stało. Broken pipeogólnie oznacza, że ​​z jakiegoś powodu nastąpiło rozłączenie sieci.
MelBurslan

Właśnie się przeprowadziłem i dzieje się tak ciągle z moim nowym połączeniem. Cox Cable to mój dostawca usług internetowych, a od instalacji mam modem kablowy Netgear C6300BD z domyślnymi ustawieniami. To się zdarzało w mojej starej lokalizacji i nigdy nie mogłem tego rozwiązać. Trwało to miesiące i ostatecznie przestało się dziać. Zapomniałem, jak to było nieszczęśliwe i nierozwiązywalne do dziś.
T. Brian Jones,

Czuję twój ból. Przybyłem tu w ostateczności, zanim zamierzam spoliczkować cały mój sprzęt na małe kawałki. Czy to nie powinien być dość prosty protokół?
DerpyNerd

Miałem ten sam błąd w zwirtualizowanym Linuksie, problem został rozwiązany, zmieniając adapter Ethernet na mostkowy
Abel Barrios

Odpowiedzi:


8

Drodzy czytelnicy 2018 i później,

Pozwól, że pokażę ci komentarz MelBurslan,

Jeśli jesteś w środowisku korporacyjnym, skontaktuj się z administratorami zapory i sprawdź, czy aktualizowali reguły i / lub ponownie uruchamiali zaporę po jakiejś zmianie, gdy to nastąpi. Jeśli dzieje się to na twoim osobistym serwerze, musisz podać więcej informacji o tym, co robiłeś po stronie serwera sshd, kiedy to się stało. Przerwana rura ogólnie oznacza, że ​​z jakiegoś powodu nastąpiło rozłączenie sieci.

Zasadniczo, jeśli próbujesz korzystać ssh username@0.0.0.0z VPN (środowisko korporacyjne). Zatem ten błąd musi być z tobą w kółko.

Jedynym rozwiązaniem, jakie do tej pory znalazłem, jest mobilna powłoka . Dzięki, kto to stworzył.

Będziesz musiał zainstalować mosh-serverw swoim systemie docelowym (serwerze, do którego chcesz ssh'ed) i mosh-clientna komputerze-hoście.

Automatycznie połączy się ponownie, gdy stracisz pakiety, to całkiem fajne i odpowiada wszystkim naszym potrzebom, tak myślę.

Happy ssh'ing!


3

Odkryłem, że był to problem opcji IPQoS w mojej konfiguracji VMware Guest. Na maszynie wirtualnej ustawiłem wartość ~ / .ssh / config dla IPQoS z wartości domyślnej „IPQoS af21 cs1”, która jest danymi o małym opóźnieniu dla pierwszej interaktywnej i mniejszej nakładu dla drugiej nieinteraktywnej. Moim rozwiązaniem było ustawienie nowej wartości dla af21:

Host *
     IPQoS throughput

Pracowałem dla mnie, w przeciwnym razie tak, MoSH również działa, ale mosh nie obsługuje mojej konfiguracji Proxy w wygodny sposób, więc trzymam się poleceń ProxyJump w


Zabawa, która działa w wierszu poleceń (jak wyjaśnisz w swoim poście na ubuntu), ale nie w pliku konfiguracyjnym 8-D
aurelien

1

Po pierwsze, upewnij się, że Twój problem nie jest z tym związany .

Jeśli nie, a problem nadal występuje, czytaj dalej.

Też doświadczyłem tego problemu i spędziłem kilka dni próbując go rozdzielić.

Jak podano, gra przy użyciu parametrów SSH KeepAlive lub parametrów TCP jądra (włączanie / wyłączanie TCPKeepAlive) nie rozwiązuje problemu.

Po zabawie ze sterownikami USB do Ethernetu i zrzutem TCP zdałem sobie sprawę, że problem był spowodowany przez jądro 4.8. Zmieniłem źródło (strona wysyłająca) na 4.4 LTS i problem zniknął (rsync, scp znów działały ładnie). Strona docelowa może pozostać na 4,8, jeśli chcesz, w moim przypadku to zadziałało (przetestowane).

Od strony technicznej możemy nieco zawęzić problem dzięki zrzutowi wireshark poniżej, który zrobiłem. Widzimy, że kanał TCP protokołu SSHv2 jest resetowany (flaga RST protokołu TCP ustawiona na 1), co powoduje przerwanie połączenia. Nie znam jeszcze przyczyny RST. Muszę w tym celu dokonać podziału na punkty od 4.8.1 do 4.8.11.wprowadź opis zdjęcia tutaj

Nie twierdzę, że twój problem wynika konkretnie z jądra 4.8, ale wrt. w dniu, w którym opublikowałeś swoje pytanie / wiadomość, być może korzystałeś z wersji jądra, która była faktycznie wadliwa.

Początkowo odpowiedział na StackOverflow .


Jądro nie stanowi problemu, ponieważ cały czas używałem 4.4 LTS. Na prawdziwy problem tutaj odpowiedział @MelBursan w komentarzu do pytania. Moje połączenie internetowe za pomocą VPN, dlatego. Rozwiązanie: mosh.org
Toan Nguyen,

@ToanNguyen Ok. W ten sposób, czy mógłbyś podać jego komentarz jako odpowiedź na twoje pytanie i oznaczyć go jako naprawiony? :-) Jeśli znalazłeś techniczne powody, dla których potrzebowałeś mosh, dodaj je również :-). Po mojej stronie mam również połączenia VPN, które działały bezbłędnie bez mosh.
wget,

Wracam do tego. Problem nie był spowodowany błędnym jądrem, ale błędnym sterownikiem, zwłaszcza częścią poświęconą odciążaniu sumy kontrolnej sprzętu. Zobacz ten wątek, aby uzyskać więcej informacji .
wget

Czy to rozwiązuje twój problem?
Toan Nguyen

@ToanNguyen Właściwie ostatnim razem, gdy miałem ten problem, po prostu obniżyłem poziom jądra i znów działało. Teraz po prostu wyłączyłem odciążanie sumy kontrolnej hw, nie obniżając niczego i to rozwiązało problem, tak.
wget

1

ssh -o IPQoS=throughput user@{ip}


Nic nie wskazuje na to, że użytkownik używa systemu macOS lub próbuje się zalogować jako root.
Kusalananda

Masz rację! Jednak przetestowałem polecenie z użytkownikiem innym niż „root” i w systemie Windows. Nadal działa!
vicky penkova

0

Otwórz plik ssh.config na serwerze docelowym za pomocą poniższego polecenia:

sudo nano /etc/ssh/ssh.config

Dodaj poniższe wiersze na końcu tego pliku

ClientAliveInterval 300

ClientAliveCountMax 2

naciśnij Ctrl + o i wprowadź.

sudo restart

To dla mnie zadziałało. Byłem w tej samej sytuacji. Próbowałem tego i tamtego, ale po prostu wykonaj następujące kroki. Tylko to. Mam nadzieję, że to również zadziała dla ciebie.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.