packet_write_wait Tubo quebrado, mesmo deixando o topo funcionando?

26

Esse erro sangrento faz minha dor de cabeça ficar cada vez maior a cada dia. Eu nunca conheci uma mesma situação como esta.

Bem, depois que eu me autentiquei no SSH com sucesso, fazendo poucos animais, minha conexão SSH caiu de repente !!?

Aqui está a minha mensagem de erro: packet_write_wait: Connection to XXX.XX.XX.XXX: Broken pipe

Gostaria que minha mensagem de erro fosse assim: Write Failed: broken pipemuito, acredite em mim!

Eu tentei muitas resoluções na Internet, como ServerAliveInterval, ServerAliveCountMax, ClientAlive ....

Alguém disse: Transforme seu TCPKeepAlive em não, acrescentou o ServerAlive bllah blah idiota. Eu fiz isso também, mas ainda o mesmo erro.

Não há sorte para mim até este momento.

Qualquer ajuda será apreciada.

ssh

— Toan Nguyen
fonte

2

Se você estiver em um ambiente corporativo, verifique com os administradores do firewall e veja se eles estavam atualizando regras e / ou reiniciando o firewall após algum tipo de alteração quando isso acontecer. Se estiver acontecendo com um servidor pessoal seu, você precisará fornecer mais informações sobre o que estava fazendo no lado do servidor sshd, quando isso aconteceu. Broken pipegeralmente significa que houve uma desconexão da rede por algum motivo.

— MelBurslan 02/02

Acabei de me mudar e isso está acontecendo constantemente com minha nova conexão. O Cox Cable é o meu ISP e tenho um modem a cabo Netgear C6300BD em execução nas configurações padrão da instalação. Isso costumava acontecer no meu antigo local e eu nunca conseguia resolvê-lo. Durou meses e acabou parando de acontecer. Eu esqueci o quão miserável e insolúvel era até hoje.

— 19716 Brian T. Jones

Eu sinto sua dor. Eu vim aqui como último recurso antes de dividir todo o meu hardware em pequenos pedaços. Isso não deveria ser um protocolo bastante simples?

— DerpyNerd

Eu tive o mesmo erro em Virtualized Linux, o problema resolvido mudando o adaptador Ethernet para ponte

— Abel Barrios

8

Caros leitores de 2018 e posteriores,

Deixe-me mostrar um comentário de MelBurslan,

Se você estiver em um ambiente corporativo, verifique com os administradores do firewall e veja se eles estavam atualizando regras e / ou reiniciando o firewall após algum tipo de alteração quando isso acontecer. Se estiver acontecendo com um servidor pessoal seu, você precisará fornecer mais informações sobre o que estava fazendo no lado do servidor sshd, quando isso aconteceu. Tubo quebrado geralmente significa que houve uma desconexão da rede por algum motivo.

Então, basicamente, se você está tentando usar ssh username@0.0.0.0em uma VPN (ambiente corporativo). Então esse erro deve estar sempre com você.

A única solução que encontrei até agora é o shell móvel . Obrigado quem o criou.

Você precisará instalar mosh-serverno seu destino (o servidor que você deseja transferir) e mosh-clientna sua máquina host.

Ele se reconectará automaticamente quando seus pacotes forem perdidos, o que é muito legal e atende a todas as nossas necessidades, eu acho.

Ssh'ing feliz!

— Toan Nguyen
fonte

3

Descobri que era um problema de opção IPQoS na minha instalação do VMware Guest. Na VM, defino o valor ~ / .ssh / config para IPQoS a partir do padrão "IPQoS af21 cs1", sendo dados de baixa latência para o primeiro interativo e menor esforço para o não interativo. Definir um novo valor para af21 foi minha solução:

Host *
     IPQoS throughput

Funcionou para mim; caso contrário, sim, o MoSH também é funcionado, mas o mosh não manipula minha configuração de Proxy de uma maneira conveniente, por isso continuo com os comandos ProxyJump em

— rupert160
fonte

Divertido, isso funciona na linha de comando (como você explica no seu post no ubuntu), mas não no arquivo de configuração 8-D

— aurelien

1

Primeiro, verifique se o seu problema não está relacionado a este .

Caso contrário, e o problema ainda está presente, continue a ler.

Também experimentei esse problema e passei alguns dias tentando identificá-lo.

Como especificado, jogar com os parâmetros SSH KeepAlive ou com os parâmetros TCP do kernel (TCPKeepAlive ativado / desativado) não resolve o problema.

Depois de jogar com drivers usb para ethernet e TCP dump, percebi que o problema era devido ao kernel 4.8. Troquei a fonte (lado de envio) para 4.4 LTS e o problema desapareceu (rsync, scp estavam funcionando muito bem novamente). O lado do destino pode permanecer em 4,8, se você quiser, no meu caso de uso isso estava funcionando (testado).

No lado técnico, podemos diminuir um pouco o problema graças ao despejo do wireshark abaixo que fiz. Podemos ver que o canal TCP do protocolo SSHv2 está sendo redefinido (o sinalizador RST do TCP está definido como 1), causando o cancelamento da conexão. Ainda não sei a causa do RST. Preciso fazer uma bissecção de 4.8.1 a 4.8.11 para isso.

Não estou dizendo que seu problema se deva especificamente ao kernel 4.8, mas wrt. Na data em que você postou sua pergunta / mensagem, você pode estar usando uma versão do kernel que era realmente de buggy.

Respondeu inicialmente no StackOverflow .

— wget
fonte

Kernel não é o problema, porque eu estava usando 4.4 LTS o tempo todo. O verdadeiro problema aqui foi respondido por @MelBursan no comentário da pergunta. Minha conexão de internet usando VPN, é por isso. Solução: mosh.org

— Toan Nguyen

@ToanNguyen Ok. Dessa forma, você poderia colocar o comentário dele como resposta à sua pergunta e marcá-lo como corrigido? :-) Se você encontrou os motivos técnicos pelos quais precisava do mosh, adicione-os também :-). Do meu lado, também tenho conexões VPN e elas estavam funcionando perfeitamente sem o uso do mosh.

— Wget #

Estou voltando a isso. O problema não era devido a um kernel com erros, mas a um driver com erros, especialmente a parte dedicada à descarga da soma de verificação de hardware. Veja este tópico para mais informações .

— Wget

Isso resolve o seu problema?

— Toan Nguyen

@ToanNguyen Na verdade, da última vez que tive esse problema, simplesmente desclassifiquei o kernel e ele estava funcionando novamente. Agora, simplesmente desabilitei o descarregamento da soma de verificação hw, sem fazer o downgrade de nada e resolvi o problema, sim.

— Wget

1

ssh -o IPQoS=throughput user@{ip}

— vicky penkova
fonte

Não há indicação de que o usuário esteja usando o macOS ou que esteja tentando fazer login como root.

— Kusalananda

Você está certo! No entanto, testei o comando com um usuário diferente de 'root' e no Windows. Ainda funciona!

— vicky penkova

0

Abra o arquivo ssh.config no servidor de destino com o comando abaixo:

sudo nano /etc/ssh/ssh.config

Adicione as linhas abaixo no final desse arquivo

ClientAliveInterval 300

ClientAliveCountMax 2

pressione Ctrl + oe digite.

reinicialização do sudo

Isso funcionou intensamente para mim. Eu estava na mesma situação. Tentei isso e aquilo, mas apenas siga estas etapas. Só isso. Espero que funcione para você também.

— DonFeraRRi
fonte