calcul de checksum (réglé)

calcul de checksum (réglé) - Divers - Programmation

Marsh Posté le 20-10-2018 à 17:09:27    

Bonjour :hello: ,
 
J'ai un problème avec un calcul de checksum / vérification de l'intégrité d'un paquet de données. C'est pourtant tout bête mais je dois avoir un blocage dans mon cerveau... :o  
 
Le checksum est défini ainsi:

Citation :

the two's complement of the modulo 256 sum of all the octets in the message


Voici les données en hexa:

80 24 02 0A 30 31 32 33 34 35 36 37 38 39 01 08 30 31 30 31 30 31 30 31 07 0C 4E 65 75 66 62 6F 78 20 54 65 73 74 0C


Et le checksum correct à 99,99%: 0xF8
 
Pourtant si j'ajoute tout les octets

Code :
  1. use strict;
  2. use warnings;
  3.  
  4. my $a;
  5. foreach $_ (qw(80 24 02 0A 30 31 32 33 34 35 36 37 38 39 01 08 30 31 30 31 30 31 30 31 07 0C 4E 65 75 66 62 6F 78 20 54 65 73 74 0C))
  6. {
  7.     $a+=hex($_);
  8. }
  9. printf("%x\n",$a);

j'obtiens 0x900 soit 0x00 après modulo 256 ce qui n'a strictement rien à voir avec 0xF8.
 
J'arrive pas à trouver l'erreur, un coup de main svp. :o  :jap:


Message édité par rat de combat le 22-10-2018 à 20:19:10
Reply

Marsh Posté le 20-10-2018 à 17:09:27   

Reply

Marsh Posté le 20-10-2018 à 18:23:46    

Pourquoi 99,99 % ?
 
Les données sont-elles bonnes ?


---------------
C'est en écrivant n'importe quoi qu'on devient n'importe qui.
Reply

Marsh Posté le 20-10-2018 à 18:38:51    

De toute façon ça ne veut rien dire "les deux compléments à xxx". Il n'y a qu'un complément à 256 même si ça se représente par 2 caractères en hexa.


---------------
C'est en écrivant n'importe quoi qu'on devient n'importe qui.
Reply

Marsh Posté le 20-10-2018 à 19:01:32    

MaybeEijOrNot a écrit :

De toute façon ça ne veut rien dire "les deux compléments à xxx". Il n'y a qu'un complément à 256 même si ça se représente par 2 caractères en hexa.

C'est pas "deux compléments" mais le complément à 2, à différencier du complément à 1.

MaybeEijOrNot a écrit :

Pourquoi 99,99 % ?

Le tout à transité à travers une liaison série, il y a donc une possibilité de corruption mais elle est très petite.

Citation :

Les données sont-elles bonnes ?

Oui.

Reply

Marsh Posté le 20-10-2018 à 20:06:21    

rat de combat a écrit :

C'est pas "deux compléments" mais le complément à 2, à différencier du complément à 1.


 
Non mais en plus c'est ce que j'ai fait. xD


---------------
C'est en écrivant n'importe quoi qu'on devient n'importe qui.
Reply

Marsh Posté le 21-10-2018 à 16:36:21    

J'arrive au même résultat que toi. Ca serait bien d'être sûr des données de base (paquet de bit et checksum).
Pour info en calculant le modulo 255 au lieu de 256 j'arrive à F7 (qui ressemble beaucoup à F8, mais c'est peut être un hasard total :whistle: )
 
Test à l'arrache en C# (avec 255) :  

Code :
  1. string val = "80 24 02 0A 30 31 32 33 34 35 36 37 38 39 01 08 30 31 30 31 30 31 30 31 07 0C 4E 65 75 66 62 6F 78 20 54 65 73 74 0C";
  2. var hexs = val.Split(' ');
  3. uint sum = 0;
  4. foreach(var hex in hexs)
  5. {
  6. sum += uint.Parse(hex, NumberStyles.HexNumber);
  7. }
  8. sum.Dump("Sum" );
  9. byte mod = (byte) (sum % 255);
  10. mod.ToString("X2" ).Dump("Mod hexa" );
  11. var cp2 = (byte)( ~mod + 1);
  12. cp2.ToString("X2" ).Dump("Complement à 2" );


Ca dit :  
Sum : 2304  
Mod hexa : 09  
Complement à 2 : F7  


---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
Reply

Marsh Posté le 21-10-2018 à 17:34:47    

Si tu fais la somme de tous tes octets, que tu fais ta somme modulo 255 puis le complément à 257 ça fonctionne. Mais ça n'a en effet aucun sens si ce n'est peut être l'erreur de croire que le complément à 2 pour 1 octet serait le complément à 255+2 (au lieu de 255+1).


---------------
C'est en écrivant n'importe quoi qu'on devient n'importe qui.
Reply

Marsh Posté le 21-10-2018 à 17:39:45    

Ca revient à mon exemple si je te suis bien. Mais effectivement ça demande beaucoup de changements un poil arbitraires :d.
Comme je disais il faudrait vérifier la validité de l'exemple d'origine, ou à défaut en avoir d'autres (trame + checksum) pour vérifier si on arrive à trouver systématiquement les même résultats concordant.


Message édité par TotalRecall le 21-10-2018 à 17:40:20

---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
Reply

Marsh Posté le 21-10-2018 à 17:45:09    

Merci pour vos réponses, je vais regarder ça courant semaine prochaine. :jap:

Reply

Marsh Posté le 21-10-2018 à 17:46:12    

Sinon à la place de prendre le reste de la somme modulo 255 tu peux aussi retenir le nombre de fois que ta somme est divisible par 256, ça donne aussi 9...

 

EDIT : une autre trame + checksum devrait trancher.


Message édité par MaybeEijOrNot le 21-10-2018 à 17:46:50

---------------
C'est en écrivant n'importe quoi qu'on devient n'importe qui.
Reply

Marsh Posté le 21-10-2018 à 17:46:12   

Reply

Marsh Posté le 21-10-2018 à 17:53:34    

Ah ouais tiens, 2304 / 256 ça fait aussi 9, marrant. Mais avec le complément à deux ça ne fait toujours pas F8 et surtout c'est bizarre pour un checksum puisque ça viendrait ignorer tte la partie décimale (au contraire du modulo), donc aucun intéret IMHO !


Message édité par TotalRecall le 21-10-2018 à 17:53:57

---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
Reply

Marsh Posté le 21-10-2018 à 17:57:50    

Ah oui ça serait clairement catastrophique pour un checksum de faire ça, cela impliquerait que des petits changements permettrait d'obtenir le même checksum.


---------------
C'est en écrivant n'importe quoi qu'on devient n'importe qui.
Reply

Marsh Posté le 21-10-2018 à 23:12:10    

>j'obtiens 0x900 soit 0x00 après modulo 256 ce qui n'a strictement rien à voir avec 0xF8.  
Perso, ça me semble bon.
Pour le checksum de la somme, tu peux faire  
$checksum=((($sum^255)+1)&255);
 
A+,


---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --  AngularJS c'est un framework d'engulé!  --
Reply

Marsh Posté le 22-10-2018 à 20:18:57    

Bon, j'ai généré une autre trame et j'ai trouvé, c'était vraiment tout bête: J'ai pris le mauvais octet... :o En fait le F8 je ne sais pas ce qu'il vient faire là, le checksum c'est 0C (l'octet d'avant) et du coup ça colle. Je l'avais pris pour un \r ou \n (je sais plus) dans le champ précédant, pas de chance que ça tombe sur cette valeur...
 
Merci pour votre aide. :jap:

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed