Вопросы Теги

packet_write_wait Broken pipe even leaving top running?

Вы должны добавить в свой /etc/apt/sources.list файл ( источник ): 

deb http://http.kali.org/kali kali-rolling main contrib non-free
# For source package access, uncomment the following line
# deb-src http://http.kali.org/kali kali-rolling main contrib non-free

Затем обновите репозитории и установите заголовки: 

sudo apt-get update
sudo apt-get install linux-headers-$(uname -r)

27
02.02.2016, 06:16
5 ответов

Во-первых, убедитесь, что ваша проблема не связана с этой .

Если нет и проблема все еще существует, продолжайте читать.

Я тоже столкнулся с этой проблемой и несколько дней пытался ее решить.

Как указано, игра с параметрами SSH KeepAlive или TCP-параметрами ядра (включение / выключение TCPKeepAlive) не решает проблему.

После экспериментов с драйверами USB-Ethernet и дампа TCP я понял, что проблема связана с ядром 4.8. Я переключил источник (отправляющую сторону) на 4.4 LTS, и проблема исчезла (rsync, scp снова работали нормально). Сторона назначения может остаться на 4.8, если хотите, в моем случае использования это работало (проверено).

С технической стороны, мы можем немного сузить проблему благодаря дампу wirehark, который я сделал ниже. Мы видим, что канал TCP протокола SSHv2 сбрасывается (флаг RST TCP установлен в 1), что приводит к разрыву соединения. Я пока не знаю причину RST. Для этого мне нужно сделать немного пополам от 4.8.1 до 4.8.11. enter image description here

Я не говорю, что ваша проблема связана именно с ядром 4.8, но с wrt. дата, когда вы разместили свой вопрос / сообщение, возможно, вы использовали версию ядра, которая действительно содержала ошибки.

Первоначально ответ был на StackOverflow .

1
27.01.2020, 19:39

Откройте файл ssh.config на целевом сервере с помощью приведенной ниже команды:

sudo nano /etc/ssh/ssh.config

Добавьте следующие строки в конец этого файла

ClientAliveInterval 300

ClientAliveCountMax 2

нажмите Ctrl+o и введите.

sudo reboot

Это действительно сработало для меня. Я был в такой же ситуации. Пробовал то и это, но просто следуйте этим шагам. Только это. Я надеюсь, что это сработает и для вас.

0
27.01.2020, 19:39

Я обнаружил, что проблема связана с параметром IPQoS при установке VMware Guest. На виртуальной машине я установил значение ~/.ssh/config для IPQoS из значения по умолчанию «IPQoS af21 cs1», которое представляет собой данные с низкой задержкой для интерактивного первого и с меньшими усилиями для не -интерактивного для второго. Установка нового значения для af21 была моим решением :

. 
Host *
     IPQoS throughput

У меня сработало, в остальном да, MoSH тоже работает, но mosh не обрабатывает мою настройку прокси удобным способом, поэтому я придерживаюсь команд ProxyJump в

4
27.01.2020, 19:39

ssh -o IPQoS=throughput user@{ip}

1
27.01.2020, 19:39

Я постоянно получал эту ошибку при удаленном подключении к серверу, расположенному в моем офисе. Мы не используем VPN, поэтому все внешние подключения проходят через прокси-сервер. ИТ-отдел предоставил следующую запись конфигурации SSH, которую я скопировал прямо в свой~/.ssh/config:

Host xx.xx.xx.xx
  ProxyCommand ssh username@proxyserver exec netcat -w 5 %h %p

Я не знаю, почему они включили -w 5, потому что это устанавливает очень короткий тайм-аут в 5 секунд бездействия, прежде чем соединение будет разорвано. Удаление или увеличение параметра -wустраняет проблему (, равно как и переключение только на ProxyJump username@proxyserver, что сейчас рекомендует ИТ-отдел ).

1
07.04.2020, 20:58

Теги

Похожие вопросы