packet_write_wait La pipe spezzata lascia anche il top in esecuzione?

26

Questo sanguinoso errore fa sì che il mio mal di testa diventi sempre più grande ogni giorno. Non ho mai incontrato una stessa situazione come questa volta.

Bene, dopo che mi sono autenticato con successo su SSH, facendo alcune cose allora la mia connessione SSH viene interrotta improvvisamente !!?

Ecco il mio messaggio di errore: packet_write_wait: Connection to XXX.XX.XX.XXX: Broken pipe

Ho desiderato che il mio messaggio di errore fosse simile al seguente: Write Failed: broken pipe molto, credimi!

Ho provato un sacco di risoluzione su Internet come aggiunto ServerAliveInterval, ServerAliveCountMax, ClientAlive ....

Qualcuno ha detto: trasforma TCPKeepAlive su no, ha aggiunto ServerAlive bllah blah idiota. Ho fatto anche quello, ma sempre lo stesso errore.

Non c'è fortuna per me fino a questo momento.

Qualsiasi aiuto sarà apprezzato.

ssh

— Toan Nguyen
fonte

2

Se ci si trova in un ambiente aziendale, verificare con gli amministratori del firewall e vedere se stavano aggiornando le regole e / o riavviando il firewall dopo una sorta di modifica quando ciò accade. Se sta accadendo a un tuo server personale, devi fornire ulteriori informazioni su cosa stavi facendo sul lato server sshd, quando ciò è accaduto. Broken pipegeneralmente significa che c'era una disconnessione di rete per qualche motivo.

— MelBurslan,

Mi sono appena trasferito e questo accade costantemente con la mia nuova connessione. Cox Cable è il mio ISP e ho un modem via cavo Netgear C6300BD in esecuzione con le impostazioni predefinite dall'installazione. Questo accadeva nella mia vecchia posizione e non riuscivo mai a risolverlo. È durato per mesi e alla fine ha smesso di accadere. Ho dimenticato quanto fosse miserabile e irrisolvibile fino ad oggi.

— T. Brian Jones,

Condivido il tuo dolore. Sono venuto qui come ultima risorsa prima di andare a schiaffeggiare tutto il mio hardware in minuscoli pezzi. Non si suppone che questo sia un protocollo abbastanza semplice?

— DerpyNerd,

Ho avuto lo stesso errore su Virtualized Linux, il problema è stato risolto cambiando l'adattatore Ethernet in bridge

— Abel Barrios,

8

Cari lettori 2018 e successivi,

Lascia che ti mostri un commento di MelBurslan,

Se ci si trova in un ambiente aziendale, verificare con gli amministratori del firewall e vedere se stavano aggiornando le regole e / o riavviando il firewall dopo una sorta di modifica quando ciò accade. Se sta accadendo a un tuo server personale, devi fornire ulteriori informazioni su cosa stavi facendo sul lato server sshd, quando ciò è accaduto. Il tubo rotto in genere significa che c'era una disconnessione della rete per qualche motivo.

Quindi, in pratica, se stai cercando di usare ssh username@0.0.0.0 su una VPN (ambiente aziendale). Quindi questo errore deve essere sempre presente.

L'unica soluzione che ho trovato finora è mobile-shell . Grazie per averlo creato.

Dovrai installare mosh-serversul tuo target (il server su cui vuoi collegarti) emosh-client sul tuo computer host.

Si riconnetterà automaticamente quando i pacchetti vengono persi, è piuttosto interessante e soddisfa tutte le nostre esigenze, credo.

Buona festa!

— Toan Nguyen
fonte

3

Ho scoperto che si trattava di un problema relativo all'opzione IPQoS nella configurazione del mio guest VMware. Sulla VM ho impostato il valore ~ / .ssh / config per IPQoS dal valore predefinito di "IPQoS af21 cs1", ovvero dati a bassa latenza per il primo interattivo e minore sforzo per il non interattivo per il secondo. L'impostazione di un nuovo valore per af21 è stata la mia soluzione:

Host *
     IPQoS throughput

Ha funzionato per me, altrimenti sì, anche MoSH ha funzionato, ma mosh non gestisce la mia configurazione Proxy in modo conveniente, quindi mi attengo ai comandi ProxyJump in

— rupert160
fonte

Divertente, che funziona nella riga di comando (come spieghi nel tuo post su Ubuntu) ma non nel file di configurazione 8-D

— aurelien

1

Innanzitutto, assicurati che il tuo problema non sia correlato a questo .

In caso contrario e il problema è ancora presente, continua a leggere.

Ho riscontrato anche questo problema e ho trascorso alcuni giorni a tentare di bissarlo.

Come specificato, giocare con i parametri SSH KeepAlive o con i parametri TCP del kernel (TCPKeepAlive on / off) non risolve il problema.

Dopo aver giocato con i driver da USB a Ethernet e il dump TCP, mi sono reso conto che il problema era dovuto al kernel 4.8. Ho commutato la fonte (lato invio) a 4.4 LTS e il problema è scomparso (rsync, scp funzionavano di nuovo bene). Se vuoi, il lato di destinazione può rimanere su 4.8, nel mio caso d'uso funzionava (testato).

Dal punto di vista tecnico, possiamo restringere un po 'il problema grazie alla discarica di wirehark sotto che ho realizzato. Possiamo vedere che il canale TCP del protocollo SSHv2 viene ripristinato (flag RST di TCP impostato su 1) causando l'interruzione della connessione. Non conosco ancora la causa dell'RST. A tale scopo, devo effettuare alcune dissezioni dal 4.8.1 al 4.8.11.

Non sto dicendo che il tuo problema sia dovuto in particolare al kernel 4.8, ma wrt. la data in cui hai pubblicato la tua domanda / messaggio, potresti aver usato una versione del kernel che era effettivamente difettosa.

Inizialmente risposto su StackOverflow .

— wget
fonte

Il kernel non è il problema, perché usavo sempre 4.4 LTS. Il vero problema qui è stato risolto da @MelBursan nel commento della domanda. La mia connessione Internet tramite VPN, ecco perché. Soluzione: mosh.org

— Toan Nguyen il

@ToanNguyen Ok. In questo modo, potresti per favore inserire il suo commento come risposta alla tua domanda e contrassegnarlo come fisso? :-) Se hai trovato i motivi tecnici per cui avevi bisogno di mosh, aggiungili anche tu :-). Da parte mia, ho anche connessioni VPN e queste funzionavano perfettamente senza mosh.

— wget,

Sto tornando su questo. Il problema non era dovuto a un kernel difettoso, ma a un driver difettoso, in particolare la parte dedicata all'offload del checksum hardware. Vedi questa discussione per maggiori informazioni .

— wget,

Risolve il tuo problema?

— Toan Nguyen,

@ToanNguyen In realtà l'ultima volta che ho avuto questo problema ho semplicemente declassato il kernel e funzionava di nuovo. Ora, ho semplicemente disabilitato l'offload del checksum hw, senza effettuare il downgrade di nulla e ho risolto il problema, sì.

— wget,

1

ssh -o IPQoS=throughput user@{ip}

— Vicky Penkova
fonte

Non ci sono indicazioni che l'utente stia usando macOS o che stiano tentando di accedere come root.

— Kusalananda

Hai ragione! Tuttavia, ho testato il comando con un utente diverso da "root" e su Windows. Funziona ancora!

— vicky penkova,

0

Aprire il file ssh.config sul server di destinazione con il comando seguente:

sudo nano /etc/ssh/ssh.config

Aggiungi le righe sottostanti alla fine di quel file

ClientAliveInterval 300

ClientAliveCountMax 2

premi Ctrl + o e inserisci.

riavvio sudo

Questo ha funzionato acutamente per me. Ero nella stessa situazione. Ho provato questo e quello, ma basta seguire questi passaggi. Solo questo. Spero che funzionerà anche per te.

— DonFeraRRi
fonte