Prefiro suspeitar de um bug no recurso "comparar por conteúdo" dos TCs e verificar novamente usando a geração de soma de verificação local para os arquivos em ambos os lados usando algo como MD5 ou SHA-1 hashes e comparando as somas de verificação visualmente.
Algum raciocínio
Um quadro Ethernet possui uma soma de verificação CRC de 32 bits por quadro. TCP adiciona uma soma de verificação CRC de 16 bits. Um pacote defeituoso com um erro de bit único passando em ambas as somas de verificação seria menos provável do que para uma única verificação CRC de 32 bits (2 ^ -32), mas mais provável que o produto de ambas as probabilidades (2 ^ -16 * 2 ^ - 32 = 2 ^ -48). Onde exatamente, depende das características dos algoritmos.
Assumindo um tamanho de carga útil de 1.400 Bytes (ou seja, se você não estiver usando Jumbo Frames) e arredondando-o para 2048 bytes para cálculos mais fáceis, significaria um erro a cada 2 ^ 42 a 2 ^ 58 Bytes (5,4 Terabytes para 250 Petabytes) se cada quadro transmitido tiver um erro de byte único .
Isso, no entanto, certamente seria notado de outra forma - uma taxa de falhas de checksum de CRC tão altas virtualmente apagaria suas transmissões de Ethernet - você obteria taxas de transferência extremamente baixas para sua cópia de arquivo. E você poderá ver muitas falhas de verificação de CRC nos contadores de portas RMON dos switches gerenciados.Assim, dada a natureza do seu erro, parece bastante improvável que seja um erro de transmissão - esses também pareceriam consideravelmente mais aleatórios.