packet_write_wait ¿Tubería rota incluso dejando la parte superior funcionando?

26

Este error sangriento hace que mi dolor de cabeza se haga más y más grande cada día. Nunca conocí una misma situación como esta vez.

Bueno, después de autenticarme en SSH con éxito, hacer algunas cosas y luego mi conexión SSH se cortó de repente.

Aquí está mi mensaje de error: packet_write_wait: Connection to XXX.XX.XX.XXX: Broken pipe

Deseaba que mi mensaje de error se viera así: Write Failed: broken pipemucho, ¡créanme!

Intenté toneladas de resolución en Internet como ServerAliveInterval, ServerAliveCountMax, ClientAlive ...

Alguien dijo: Convierta su TCPKeepAlive en no, agregó ServerAlive bllah blah idiot. Lo hice también pero sigue siendo el mismo error.

No hay suerte para mí hasta este momento.

Cualquier ayuda será apreciada.

ssh

— Toan Nguyen
fuente

2

Si se encuentra en un entorno corporativo, verifique con los administradores de su firewall y vea si estaban actualizando las reglas y / o reiniciando el firewall después de algún tipo de cambio cuando esto sucede. Si le está sucediendo a un servidor personal suyo, debe proporcionar más información sobre lo que estaba haciendo en el lado del servidor sshd, cuando esto sucedió. Broken pipegeneralmente significa que hubo una desconexión de la red por alguna razón.

— MelBurslan

Me acabo de mudar y esto sucede constantemente con mi nueva conexión. Cox Cable es mi ISP, y tengo un cable módem Netgear C6300BD con la configuración predeterminada desde la instalación. Esto solía ocurrir en mi antigua ubicación y nunca pude resolverlo. Duró meses y finalmente dejó de suceder. Olvidé lo miserable e irresoluble que era hasta hoy.

— T. Brian Jones

Siento tu dolor. Vine aquí como último recurso antes de romper todo mi hardware en pequeños pedazos. ¿No se supone que es un protocolo bastante simple?

— DerpyNerd

Tuve el mismo error en Linux virtualizado, el problema se resolvió cambiando el adaptador de ethernet a puente

— Abel Barrios

8

Estimados lectores de 2018 y posteriores,

Déjame mostrarte un comentario de MelBurslan,

Si se encuentra en un entorno corporativo, verifique con los administradores de su firewall y vea si estaban actualizando las reglas y / o reiniciando el firewall después de algún tipo de cambio cuando esto sucede. Si le está sucediendo a un servidor personal suyo, debe proporcionar más información sobre lo que estaba haciendo en el lado del servidor sshd, cuando esto sucedió. La tubería rota generalmente significa que hubo una desconexión de la red por alguna razón.

Básicamente, si está intentando utilizar ssh username@0.0.0.0una VPN (entorno corporativo). Entonces este error debe estar ahí contigo una y otra vez.

La única solución que encontré hasta ahora es mobile-shell . Gracias quien lo creó.

Deberá instalarlo mosh-serveren su destino (el servidor al que desea enviar) y mosh-clienten su máquina host.

Se volverá a conectar automáticamente cuando se pierdan sus paquetes, eso es genial y se adapta a todas nuestras necesidades, creo.

¡Feliz mierda!

— Toan Nguyen
fuente

3

Descubrí que era un problema de la opción IPQoS en mi configuración de VMware Guest. En la VM configuré el valor ~ / .ssh / config para IPQoS desde el valor predeterminado de "IPQoS af21 cs1", que son datos de baja latencia para el primer interactivo y menor esfuerzo para el no interactivo para el segundo. Establecer un nuevo valor para af21 fue mi solución:

Host *
     IPQoS throughput

Funcionó para mí, de lo contrario, sí, MoSH también funciona, pero mosh no maneja mi configuración de Proxy de una manera conveniente, así que me quedo con los comandos de ProxyJump en

— rupert160
fuente

Diversión, eso funciona en la línea de comandos (como explica en su publicación en ubuntu) pero no en el archivo de configuración 8-D

— aurelien

1

Primero, asegúrese de que su problema no esté relacionado con este .

Si no, y el problema sigue presente, sigue leyendo.

También experimenté este problema y pasé unos días tratando de solucionarlo.

Como se especifica, jugar con los parámetros SSH KeepAlive o los parámetros TCP del núcleo (TCPKeepAlive activado / desactivado) no resuelve el problema.

Después de jugar con controladores usb a ethernet y volcado TCP, me di cuenta de que el problema se debía al kernel 4.8. Cambié la fuente (lado de envío) a 4.4 LTS y el problema desapareció (rsync, scp estaban funcionando bien nuevamente). El lado de destino puede permanecer en 4.8 si lo desea, en mi caso de uso esto estaba funcionando (probado).

En el aspecto técnico, podemos reducir un poco el problema gracias al volcado de wirehark que hice a continuación. Podemos ver que el canal TCP del protocolo SSHv2 se está restableciendo (el indicador RST del TCP está configurado en 1), lo que hace que la conexión se cancele. Todavía no sé la causa del RST. Necesito hacer una bisección de 4.8.1 a 4.8.11 para eso.

No digo que su problema se deba específicamente al kernel 4.8, sino a wrt. En la fecha en que publicó su pregunta / mensaje, es posible que haya estado utilizando una versión del núcleo que en realidad tenía errores.

Respondió inicialmente en StackOverflow .

— wget
fuente

Kernel no es el problema, porque estaba usando 4.4 LTS todo el tiempo. El verdadero problema aquí fue respondido por @MelBursan en el comentario de la pregunta. Mi conexión a internet usando VPN, es por eso. Solución: mosh.org

— Toan Nguyen

@ToanNguyen Ok. De esa manera, ¿podría poner su comentario como respuesta a su pregunta y marcarlo como fijo? :-) Si ha encontrado los motivos técnicos por los que necesitaba mosh, agréguelos también :-). Por mi parte, también tengo conexiones VPN y estas estaban funcionando perfectamente sin mosh.

— wget

Estoy volviendo a esto. El problema no se debió a un kernel defectuoso, sino a un controlador defectuoso, especialmente la parte dedicada a la descarga de la suma de comprobación de hardware. Vea este hilo para más información .

— wget

¿Resuelve tu problema?

— Toan Nguyen

@ToanNguyen En realidad, la última vez que tuve este problema, simplemente bajé el kernel y estaba funcionando nuevamente. Ahora, simplemente deshabilité la descarga de la suma de comprobación hw, sin degradar nada y resolvió el problema, sí.

— wget

1

ssh -o IPQoS=throughput user@{ip}

— vicky penkova
fuente

No hay indicios de que el usuario esté usando macOS o de que esté intentando iniciar sesión como root.

— Kusalananda

¡Tienes razón! Sin embargo, probé el comando con un usuario diferente a 'root' y en Windows. ¡Todavía funciona!

— Vicky Penkova

0

Abra el archivo ssh.config en el servidor de destino con el siguiente comando:

sudo nano /etc/ssh/ssh.config

Agregue las siguientes líneas al final de ese archivo

ClientAliveInterval 300

ClientAliveCountMax 2

presione Ctrl + o e ingrese.

reinicio de sudo

Esto me funcionó muy bien. Yo estaba en la misma situación. Intenté esto y aquello, pero solo sigue estos pasos. Solo esto. Espero que también funcione para ti.

— DonFeraRRi
fuente