похожие темы
Моя проблема похожа, но не совсем такая же, какSSH сломанный канал, неверный код аутентификации сообщенияна который нет ответа.
Задача
Копировать большие файлы с одного Linux на другой. Оба находятся в одном месте у ISP.
Настраивать
Источник и цель: Ubuntu 16.04.3 LTS
Версия SSH на обоих: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 марта 2016 г.
Исходная машина используется уже год, проблем нет. Целевая машина — недавно настроенный выделенный сервер (1 день).
Команда scp:
scp -P [customport] /some/large/file user@targetmachine:/target/folder/
Размер файла составляет около 20 ГБ.
Описание проблемы
Обычно прерывается примерно через 3-4%. Полная скорость составляет около 112 МБ/с. Когда я ограничиваю ее, например, с помощью scp -l 16384, она достигает около 2 МБ/с, прерывается гораздо позже, но при аналогичном проценте.
Прерывание всегда происходит одинаково. Клиент получает:
Write failed: Broken pipe
lost connection
В то время как на сервере это есть в /var/log/auth.log
Nov 24 13:04:54 Ubuntu-1604-xenial-64-minimal-no-hwe sshd[1900]: Corrupted MAC on input.
Nov 24 13:04:54 Ubuntu-1604-xenial-64-minimal-no-hwe sshd[1900]: fatal: ssh_dispatch_run_fatal: Connection from [client-ip] port 54050: message authentication code incorrect
Расследование
Я пробовал и с включенным, и с отключенным iptables, никаких изменений.
Из примерно 10 попыток одна была успешно завершена, затем загрузка следующего файла снова прервалась.
Похоже, что после перезагрузки целевой машины на нее можно записать больше байтов.
SSH не проблема. Я могу часами держать открытым неактивное ssh-соединение или такое, где top
команда выполняется, и оно не прерывается.
Вопросы
Это блокировщик. Во-первых, кажется невозможным скопировать файл размером 200 ГБ. Во-вторых, я не хочу, чтобы машина в производстве имела проблемы с сетью.
Что я могу сделать для дальнейшего расследования этого вопроса?
Я где-то читал, что это может быть проблема с сетевой картой или оборудованием. Как я могу доказать это своему провайдеру, чтобы получить замену?
Обновление 1
Результат за 10 минут mtr
выглядит хорошо:
└─(~)─(49 files, 12Gb)─> mtr -r -c 600 -rw [targetserver]
Start: Fri Nov 24 18:36:21 2017
HOST: Ubuntu-1404-trusty-64-minimal Loss% Snt Last Avg Best Wrst StDev
1.|-- static.XX.XX.XX.XX.clients.your-server.de 0.0% 600 0.5 0.3 0.2 24.5 1.3
2.|-- core24.fsn1.hetzner.com 0.0% 600 0.3 0.3 0.2 6.8 0.4
3.|-- core22.fsn1.hetzner.com 0.0% 600 0.4 0.4 0.3 9.7 0.8
4.|-- ex9k2.dc1.fsn1.hetzner.com 0.0% 600 0.4 0.5 0.3 6.8 0.8
5.|-- my.target.hostname 0.0% 600 0.4 0.3 0.3 0.4 0.0
┌(myuser@Ubuntu-1404-trusty-64-minimal)─(✓)─(06:46 PM Fri Nov 24)
Сразу после этого я попробовал другой scp, он упал на 44% после 7,5 ГБ, скорость была 111 МБ/сек. Сбой снова произошел мгновенно, никаких остановок до этого не было.
Что касается возможного дубликата: я всегда получал "сломанную трубу", никогда "Неправильный тип протокола для сокета". Не использую Mac, оба Linux (версии выше). Не использую rsync. Ответ там был, что пользователь вставил другую сетевую карту в сервер, не выяснив, в чем была настоящая причина, насколько я понимаю. У меня нет такой возможности (выделенный сервер в удаленном хост-центре).
Вот вывод lshw относительно сетевой карты:
myuser@Ubuntu-1604-xenial-64-minimal-no-hwe /home/myuser # lshw -class network
*-network:0 DISABLED
description: Ethernet interface
product: NetXtreme II BCM57810 10 Gigabit Ethernet
vendor: Broadcom Corporation
physical id: 0
bus info: pci@0000:61:00.0
logical name: eth0
version: 10
serial: e0:d5:5e:1e:73:18
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm vpd msix pciexpress bus_master cap_list rom ethernet physical fibre 1000bt-fd
configuration: autonegotiation=off broadcast=yes driver=bnx2x driverversion=1.712.30-0 firmware=bc 7.14.2 latency=0 link=no multicast=yes port=fibre
resources: iomemory:14c0-14bf iomemory:14c0-14bf iomemory:14c0-14bf irq:81 memory:14c0b000000-14c0b7fffff memory:14c0a800000-14c0affffff memory:14c0b810000-14c0b81ffff memory:e5f80000-e5ffffff memory:14c0ba20000-14c0bc1ffff memory:14c0bca0000-14c0bd1ffff
*-network:1 DISABLED
description: Ethernet interface
product: NetXtreme II BCM57810 10 Gigabit Ethernet
vendor: Broadcom Corporation
physical id: 0.1
bus info: pci@0000:61:00.1
logical name: eth1
version: 10
serial: e0:d5:5e:1e:73:1a
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm vpd msix pciexpress bus_master cap_list rom ethernet physical fibre 1000bt-fd
configuration: autonegotiation=off broadcast=yes driver=bnx2x driverversion=1.712.30-0 firmware=bc 7.14.2 latency=0 link=no multicast=yes port=fibre
resources: iomemory:14c0-14bf iomemory:14c0-14bf iomemory:14c0-14bf irq:102 memory:14c0a000000-14c0a7fffff memory:14c09800000-14c09ffffff memory:14c0b800000-14c0b80ffff memory:e5f00000-e5f7ffff memory:14c0b820000-14c0ba1ffff memory:14c0bc20000-14c0bc9ffff
*-network:0
description: Ethernet interface
product: I350 Gigabit Network Connection
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:62:00.0
logical name: eth2
version: 01
serial: 6c:b3:11:23:32:18
size: 1Gbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi msix pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.3.0-k duplex=full firmware=1.63, 0x80000cbb ip=94.130.51.145 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
resources: irq:71 memory:e5900000-e59fffff memory:e5a84000-e5a87fff memory:e5a00000-e5a7ffff memory:14c0bf60000-14c0bf7ffff memory:14c0bf40000-14c0bf5ffff
*-network:1 DISABLED
description: Ethernet interface
product: I350 Gigabit Network Connection
vendor: Intel Corporation
physical id: 0.1
bus info: pci@0000:62:00.1
logical name: eth3
version: 01
serial: 6c:b3:11:23:32:19
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi msix pciexpress bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.3.0-k firmware=1.63, 0x80000cbb latency=0 link=no multicast=yes port=twisted pair
resources: irq:82 memory:e5800000-e58fffff memory:e5a80000-e5a83fff memory:14c0bf20000-14c0bf3ffff memory:14c0bf00000-14c0bf1ffff
*-network DISABLED
description: Ethernet interface
physical id: 1
logical name: virbr0-nic
serial: 52:54:00:80:b4:28
size: 10Mbit/s
capabilities: ethernet physical
configuration: autonegotiation=off broadcast=yes driver=tun driverversion=1.6 duplex=full link=no multicast=yes port=twisted pair speed=10Mbit/s
Это напомнило мне, что я установил KVM.
apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils
Но пока ни одна виртуальная машина не включена.
решение1
У меня была похожая проблема при использовании scp
или rsync
+ samba
/ cifs
.
Проблема была решена на стороне rsync
+/- обходом кэша записи с помощью при монтировании сервера на клиенте (см. samba
такжеcifs
--cache=none
rsync постоянно отключается: сломанный канал). Подробное объяснение основной причины этой проблемы дано по адресуЗаставить Linux записывать данные в сетевую файловую систему одновременно с чтением данных с локального диска.
Вы scp
можете рассмотреть возможность ограничения скорости передачи данных, чтобы избежать заполнения кэша страниц до того, как диск успеет обработать их, см., например,https://stackoverflow.com/questions/30020519/broken-pipe-error-on-scp.
решение2
Это была "минимальная-no-hwe" установка. "Минимальная" версия Ubuntu, скорее всего, работала бы с самого начала.
Эти команды использовались для установки hwe в эту неисправную версию no-hwe (поэтому полная переустановка не требуется):
apt-get install --install-recommends linux-generic-hwe-16.04
shutdown -r now
После этого все копии scp работают, никаких сбоев.
Примечание: приветствие в терминале все еще отображается
"myuser@Ubuntu-1604-xenial-64-minimal-no-hwe"
хотя hwe сейчас включен.
Я еще раз поясняю поведение до этого исправления: все крупные SCP-запросы НА эту машину из разных мест были прерваны, в то время как все SCP-запросы ОТ этой машины в разные места были выполнены успешно.
Это спецификация сервераhttps://www.hetzner.de/epyc-serverхотя хостер не указывает модели материнской платы/сети.