Aborto súbito de SCP: canal interrompido, código de autenticação de mensagem incorreto

3

Tópicos relacionados

Meu problema é semelhante, mas não exatamente o mesmo que SSH quebrado pipe, código de autenticação de mensagem incorreto para o qual não há resposta.

Tarefa

Copie arquivos grandes de um Linux para outro. Ambos estão no mesmo local do ISP.

Configuração

A fonte e o alvo são ambos: Ubuntu 16.04.3 LTS

Versão SSH em ambos: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 de março de 2016

A máquina de origem está em uso há um ano, sem problemas. A máquina de destino é um servidor dedicado recém-configurado (1 dia).

comando scp:

scp -P [customport] /some/large/file user@targetmachine:/target/folder/

O arquivo tem cerca de 20 GB de tamanho.

Descrição do problema

Geralmente aborta após cerca de 3-4%. A velocidade total é de cerca de 112MB / s. Quando eu acelerei com, por exemplo, scp -l 16384, ele fica em cerca de 2MB / s, aborta muito mais tarde, mas em uma porcentagem similar.

O aborto é sempre da mesma maneira. O cliente recebe:

Write failed: Broken pipe 
lost connection

Enquanto o servidor tem isso em /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

Investigação

Eu tentei ambos com o iptables ativado e desativado, sem alteração.

Em cerca de 10 tentativas, 1 até o final, o próximo arquivo foi abortado novamente.

Parece que após a reinicialização da máquina de destino, mais bytes podem ser gravados nela.

O SSH não é problema. Eu posso manter uma conexão ssh inativa aberta por horas, ou em que o comando top esteja em execução e não quebre.

Perguntas

Este é um bloqueador. Primeiro, parece impossível copiar um arquivo de 200GB. Em segundo lugar, não quero uma máquina em produção com problemas de rede.

O que posso fazer para investigar mais sobre isso?

Li em outro lugar que pode ser um problema de placa de rede / hardware, como posso provar isso ao meu provedor para obter uma substituição?

Atualização 1

O resultado de 10 minutos mtr parece bom:

└─(~)─(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)

Logo depois que eu tentei outro scp, ele falhou em 44% após 7.5GB, a taxa foi de 111MB / seg. O fracasso veio novamente instantaneamente, sem demora antes disso.

Em relação à possível duplicação: Eu sempre tenho o "pipe quebrado", nunca o "tipo de protocolo errado para socket". Não usando o Mac, ambos Linux (versões acima). Não usando o rsync. A resposta foi que o usuário colocou outra placa de rede no servidor, sem descobrir qual era a causa real, tanto quanto eu entendo. Eu não tenho essa opção (servidor dedicado no centro de host remoto).

Aqui está a saída do lshw em relação à placa de rede:

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

Isso me lembra que eu instalei o KVM

apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

Mas nenhuma VM ainda está ativa.

    
por Gonfi den Tschal 24.11.2017 / 14:05

1 resposta

0

Esta foi uma instalação "minimal-no-hwe". A versão "minimal" do Ubuntu provavelmente teria funcionado desde o início.

Estes comandos foram usados para instalar o hwe nesta versão no-hwe com defeito (portanto, nenhuma reinstalação completa):

apt-get install --install-recommends linux-generic-hwe-16.04
shutdown -r now

Depois disso, todas as cópias do scp funcionam, sem anulações.

Uma nota lateral, a saudação no terminal ainda mostra

"myuser@Ubuntu-1604-xenial-64-minimal-no-hwe"

mesmo que esteja agora.

Eu esclareço mais uma vez o comportamento antes desta correção: Todos os scp grandes para esta máquina, de vários locais, foram abortados, enquanto todos scp FROM desta máquina, para vários locais, tiveram sucesso.

Este é o link das especificações do servidor, embora o hoster não especifique os modelos para mainboard / networking.

    
por 01.12.2017 / 08:36

Tags