"MAC corrotto all'ingresso. Packet Corrupt "sul trasferimento di file su SSH, SCP e FTP su Linux Server

aiuto su questo sarebbe grande.

Specifiche:

LAMP server Linux OS – Debian 5.0.1 CPU 4x Intel (R) Xeon (TM) 2.80GHz

Pacchetti importnti:

  • openssl – Sicurezza SSL
  • iptables – firewall per bloccare tutte le richieste tranne che cosa è consentito
  • phpmyadmin – per rendere le cose più semplici
  • ntp

Non abbiamo usato per avere un problema con questo e non sappiamo esattamente quando è accaduto o i dettagli su ciò che è stato cambiato quando è accaduto. Ma abbiamo fatto un aggiornamento e questo problema sembra aver iniziato e corrisponde all'aggiornamento. Ma each volta che cerco di trasferire i file di grandi size dal server (cioè la cartella root siti per un backup) alla mia macchina, per esempio, su SSH e SCP, ottengo quanto segue:

"MAC corrugato sull'ingresso. Disconnessione: pacchetto corrotto"

  • Ciò accade quando utilizzo SCP per copiarli. Innanzitutto si blocca, quindi dà l'errore sopra.
  • Se provo FTP, ottiene circa il 3% e si blocca completamente, incluso il programma FTP.

Non so esattamente che cosa potrebbe essere il problema qui. Mi sento come se avessi qualcosa a che fare con HMAC o HMAC2 o con la scheda di networking o software. qualche idea?

  • Esxi file ssh configuration chnages per rendere non permanente e permananet
  • Connessione SSH persa
  • Aggiornamento di openssh-server all'interno di una session ssh
  • SMB SSH tunnel usando il cliente del putty dolorosamente lento
  • Ubuntu Server SSH
  • Problema con SSH su Ubuntu - Connessione locale ok, connessione remota - Sono io o il mio ISP?
  • Accedi a D-Bus in remoto usando socat
  • Incidente del sistema e molte linee in dmesg con ssh-scan segfault
  • 3 Solutions collect form web for “"MAC corrotto all'ingresso. Packet Corrupt "sul trasferimento di file su SSH, SCP e FTP su Linux Server”

    I miei pensieri:

    Gli errori sul livello di filo devono essere eliminati dai controlli Ethernet e TCP. È ansible che il pacchetto IP frame / IP corrotto possa scivolarsi ora e poi verso i livelli superiori dello stack di networking, ma è veramente poco probabile e sicuramente non dovrebbe portre a un problema ripetibile. Perciò vedo due possibilità principali:

    1) C'è qualcuno che imbrogli la tua trasmissione, modificando i dati in transito in modo che i controlli Ethernet / IP corrispondano, ma lo strato di crittografia vede rifiuti, o 2) Più probabilmente, si ha qualche errore hardware, probabilmente CPU o RAM che danneggia i dati dopo che è stato spento. Ancora una volta, la RAM ECC dovrebbe ridurre la probabilità di questo accadere, ma la CPU che si surriscalda / si muore può giocare all'inferno con i dati.

    Non so se il TCP Offload Engine con un NIC / driver che si comporti in modo errato potrebbe produrre tali errori, ma questa linea di pensiero potrebbe spiegare (driver modificato) la correlazione dei problemi con l'aggiornamento.

    Per chiunque altro inciampa su questa domanda / risposta, posso attestare il fatto che una port NIC / ethernet difettosa (come nota Paweł) può causare l'esatta affermazione di OP (MAC corrotto in ingresso). Ho due porte ethernet, uno dei quali corrompe le trasmissioni di file di grandi size quando viene utilizzato.

    Arrestare i servizi come Samba , Apache, MySQL e ha fatto il trucco. Dopo averli fermati, la connessione non è stata terminata e sono riuscito a trasferire il file tar di 7 GB senza alcun errore "errato sul mac".

    Il file di log che dovresti vedere per vedere l'errore è / var / log / sercure

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.