Journal Problème de transfert de fichier

Posté par  .
Étiquettes : aucune
0
14
avr.
2004
J'ai une image iso sur un serveur OpenBSD 3.5, je veux la transférer par NFS sur un client linux mais le checksum entre l'image sur le serveur et l'image transférée change.
Je refais le test par FTP sur une autre machine linux cliente et le checksum change également.
On pourrait penser à un problème réseau.

Est-ce qu'un outil efficace peut détecter une éventuelle panne ou problème anormal ?

  • # Re: Problème de transfert de fichier

    Posté par  (site web personnel) . Évalué à 1.

    Tu es sur que le checksum original est correct ? Ca peut paraitre idiot mais bon...

    Sinon essai scp ?

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Problème de transfert de fichier

      Posté par  (site web personnel) . Évalué à 1.

      a mon avis scp est la meilleur chose pour toi.

      • [^] # Re: Problème de transfert de fichier

        Posté par  . Évalué à 1.

        scp rootix@ns:/mnt/d02/dist/fedora/core/1/i386/iso/yarrow-i386-disc2.iso .
        yarrow-i386-disc2.iso 2% 14MB 2.0MB/s 05:06 ETADisconnecting: Corrupted MAC on input.
        lost connection

        • [^] # Re: Problème de transfert de fichier

          Posté par  (site web personnel) . Évalué à 1.

          il est bizarre ton serveur ;)
          essaye en SSH 1, essaye de mettre à jour les SSHs vers les dernières versions de part et d'autre.

          • [^] # Re: Problème de transfert de fichier

            Posté par  . Évalué à 1.

            je n'y crois pas, vu les problèmes avec nfs, ftp. Et j'ai eu des gels de nfs par moment aussi, à mon avis, il y a un rapport entre tout ça.

        • [^] # Re: Problème de transfert de fichier

          Posté par  (site web personnel) . Évalué à 1.

          J'ai l'impression que que la carte réseau coté LAN de ton routeur/serveur est en train de rendre l'âme ou alors c'est ton hub/switch. Essai de transférer un fichier entre deux autres machines de ta LAN en utilisant ce même hub/switch. Si ça fait le même problème c'est ça. Sinon c'est la carte réseau de ton routeur/serveur. Enfin, je pense.

          Essai aussi de googler l'erreur...

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: Problème de transfert de fichier

            Posté par  . Évalué à 1.

            j'ai pensé à la carte réseau, c'est quand même une 3com, va falloir que je fasse pas mal de combinaison avant de trouver ce qui cloche.

          • [^] # Re: Problème de transfert de fichier

            Posté par  . Évalué à 1.

            Ce qui me gène, c'est que dans une pile TCP/IP/Ethernet, il y a quand meme deux points de verification d'erreur (au niveau 2 et au niveau 4). Ce qui veut dire qu'il est très rare que les des données soient corrompues lors d'un transfert (surtout si les machines sont sur le meme réseau).
            Donc je pense qu'il faut exclure toute panne réseau et essayer plutot de chercher au niveau de l'implementations des algorithmes md5sum de chaque coté.

            • [^] # Re: Problème de transfert de fichier

              Posté par  . Évalué à 1.

              Quand je télécharge les iso directement mais quand même par le réseau, le résultat de md5sum est bon. Donc je pense que md5sum est bon.
              C'est seulement quand il y a transfert depuis le disque du serveur vers un poste client.
              Donc, il y a quelque chose qui diffère entre les deux façons. Dans la méthode où ça foire, la vitesse de transfert change. Dans un cas, je suis limité par le débit ADSL alors que dans l'autre, c'est débit maximum. C'est a un rapport avec la vitesse de transfert. La carte réseau du serveur serait instable en cas de transfert rapide.

            • [^] # Re: Problème de transfert de fichier

              Posté par  (site web personnel) . Évalué à 1.

              je n'y crois pas, vu les problèmes avec nfs, ftp. Et j'ai eu des gels de nfs par moment aussi, à mon avis, il y a un rapport entre tout ça.
              Si c'est pas un problème hardware, c'est au niveau du kernel et Google a l'air de confirmer que c'est un problème matériel. Essai avec un autre OS (tomsrtbt + nc devrait faire l'affaire, Knoppix si tu as un lecteur CD bootable sur la machine) et si ça marche toujours pas c'est définitivement un problème matériel. Soit le hub/switch soit la carte réseau. Essai de connecter directement un client au serveur avec un cable croisé pour connaitre la cause exact.

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Re: Problème de transfert de fichier

    Posté par  . Évalué à 1.

    > Est-ce qu'un outil efficace peut détecter une éventuelle panne ou problème anormal ?

    regarde tes 3 sommes, si les 2 sous linux sont les memes, c'est ton md5 sur ton serveur qui marche pas :-)

    • [^] # Re: Problème de transfert de fichier

      Posté par  . Évalué à 1.

      le md5 fait sur le serveur donne les mêmes valeurs que le fichier MD5SUM sur le site où y a les iso.
      Les images, si je les prend en direct sur le site en passant à travers le serveur en tant que passerelle, ça donne des iso correctes.
      Bref, un casse-tête.

  • # Re: Problème de transfert de fichier

    Posté par  (site web personnel) . Évalué à 1.

    Ça me rappelle tous les gens que je vois sur les forums de Mandrake qui s'affole parce que la somme n'est pas la même... Alors que tout marche très bien quand même, mais bon, et que l'iso se grave et se lance très bien, sans corruption. Bref, j'ironise, comme ça, mais bon, j'en sais rien pourquoi les sommes sont jamais les mêmes.

    • [^] # Re: Problème de transfert de fichier

      Posté par  (site web personnel) . Évalué à 1.

      sans corruption

      Oui enfin si les md5sums sont différents ça veut quand même dire que le fichier original est différent du fichier copié, donc que ça a été mal copié.

      • [^] # Re: Problème de transfert de fichier

        Posté par  . Évalué à 2.

        En même temps, si les md5 sont identiques ça ne veut pas dire que ton fichier est identique à celui d'origine. La seule chose que tu peux dire quand tu as le même MD5 : "Je peux dire avec certitude que mon téléchargement n'est pas assuré d'être corrompu.".

        • [^] # Re: Problème de transfert de fichier

          Posté par  . Évalué à 1.

          Il faut quand même un gros coup de bol pour que deux fichiers de sommes MD5 identiques soient différents......
          C'est ce qui fait la force du MD5

      • [^] # Re: Problème de transfert de fichier

        Posté par  (site web personnel) . Évalué à 1.

        Justement, je commence sérieusement à avoir des doutes...
        Tout à coup, une épidémie de pirates, comme ça, sur tous les FTP du monde, et qui touche que les isos Mdk, et dont personne ne parle officiellement ? J'y crois pas, désolé.
        Un téléchargement qui a perdu des octets au passage ? Je croyais qu'il y avait des mécanismes de correction d'erreur à tous les niveaux du réseau. Et puis, quand les isos se gravent bien et se lancent bien, c'est qu'elles sont pas abimées, non ?
        Alors, vraiment, honnêtement, je commence à me poser des questions. Je sais pas où ça foire exactement, mais ça foire. Et la question de ce journal ne fait que me renforcer dans mes doutes. Bref, les MD5, moi, ça sert à faire beau.

        • [^] # Re: Problème de transfert de fichier

          Posté par  (site web personnel) . Évalué à 1.

          Il n'est pas si rare que ça que quelques bits soient modifiés au cour d'un transfert. La vérification au niveau TCP (bit de parité) marche bien s'il y a un nombre impaire de bits qui ont été modifiés mais sinon rien n'est détecté et tu te retrouve avec un fichier différent de l'original et pour autant que je sache, il n'y a rien dans HTTP ou FTP qui permette de détecter l'erreur. Par contre en utilisant un tunnel crypté (HTTPS, SFTP,...), chaque paquet est signé et est normalement vérifié donc les erreurs peuvent être corrigées directement.
          Corrigez moi si je me trompe.

          Tu peux modifier quelques bits d'un iso sans le rendre "invalide" pour autant mais certains fichiers à l'intérieur du système de fichiers risquent d'être corrompus. Bien souvent tu ne t'en rendra jamais compte mais certaines applications risquent de mystérieusement planter, l'un ou l'autre caractère d'un fichier texte aura changé,... Si quelques bits changent sur un bloc de 700Mo de données, c'est pratiquement indécelable et c'est pour ça que les "one-way hashes" (MD5, SHA-1,...) sont si utiles.

          Si tu es un peu parano, tu t'arranges pour avoir plusieurs types de signatures. Autant on a déjà pu trouver quelques collisions (deux fichiers différents qui ont la même signature) avec certains algorithmes, autant une collision "multiple" me semble vraiment improbable (genre tu as plus de chance de craquer une clé PGP en essayant des nombres au hasard avec ta caclulatrice).

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: Problème de transfert de fichier

            Posté par  (site web personnel) . Évalué à 1.

            > La vérification au niveau TCP (bit de parité) marche bien
            > s'il y a un nombre impaire de bits qui ont été modifiés

            Euh, tu confonds. Les checksum TCP sont sur plus de 1 bit, quand même ;-) (Je ne sais plus si c'est 8, 16, ou 32, mais c'est plus qu'un bit de parité)

            • [^] # Re: Problème de transfert de fichier

              Posté par  (site web personnel) . Évalué à 1.

              OK au temps pour moi, je connais pas vraiment les "détails" de TCP mais je suppose qu'un ensemble données+checksum cohérent mais erronés par rapport aux données de départ reste possible (au sens où ça arrive suffisament souvent pour que ça ne soit pas négligeable, contrairement aux empreintes MD5).

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: Problème de transfert de fichier

          Posté par  . Évalué à 1.

          Et puis, quand les isos se gravent bien et se lancent bien, c'est qu'elles sont pas abimées, non ?

          euh, je me disais la même chose jusqu'à ce que je foire une install (c'était une RH 6.2 je crois), et toujours au même moment. «Tiens, et si je vérifiais le md5 de mon image iso? Oh, il est mauvais... Tiens, bizarre, ça marche beaucoup mieux avec une iso qui a le bon md5...»

          Mon iso s'était gravée sans problème, et on pouvait même aller jusqu'au bout de l'installation si on ne cherchait pas à installer le package (latex) qui faisait tout foirer.

          Bref, depuis, md5 mauvais --> poubelle.

  • # Re: Problème de transfert de fichier

    Posté par  . Évalué à 1.

    Peut-être un problème de RAM sur le serveur d'origine...

    J'ai eu un cas similaire sur une machine et ça n'a pas été simple à trouver. Finalement, en activant la vérification de la mémoire au démarrage, une barette de 128 s'est transformée en barette de 64, et les problèmes ont disparus.

  • # Re: Problème de transfert de fichier

    Posté par  (site web personnel) . Évalué à 1.

    Pour le FTP, le truc classique, c'est d'être en mode ASCII entre deux machines gérant différament les fins de lignes.

    Pour le NFS, bizare bizare ...

    tu peux regarder du coté de xdelta pour savoir si les fichiers diffèrent beaucoup ou pas.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.