Discussion :

[304bl]

Bonjour a tous,

j'ai actuellement un probleme de convertion int -> byte
ce probleme a deja etait traiter pas mal de fois dans plusieurs topic me dirai vous, mais les reponse trouver ne me permette pas de regler mon probleme dans mon contexte.

je travaille actuellement avec le librairie jpcap (capture et envoi de packet sur le reseau) et mon probleme survient lorsque je souhaite injecter des packets.

je recupere les ou le packet(s) a injecter a partir d'un fichier texte qui contient toute les valeur du packet original en hexa (0xd4,0x12...) apres avoir fait ce qu'il faut j'ai au final un tableau de int qui contient mes valeur hexa convertit.

Pour pouvoir injecter un packet je doit dabort le crée et pour cela le constructeur de cette classe me demande exclusivement un tableau de byte,
or vous le savez deja les byte sont signé et donc la conversion par exemple de la valeur 0xd4 donne au final 2 byte en java, mais si je suis cette logique le tableau final que je vais passer au constructeur du packet sera plus grand que celui du packet original.

d'ou ma question cela va t-il etre mal interpreter sur le reseau ?
si oui comment puis-je donner un tableau de byte correct ?

[thelvin]

or vous le savez deja les byte sont signé et donc la conversion par exemple de la valeur 0xd4 donne au final 2 byte en java

Quoi ? pas du tout, ça donne juste un byte négatif.

Je sais que c'est pas évident, mais les bytes sont capables de contenir 256 valeurs différentes. Ces valeurs, d'après Java, sont -128 à 127 ; au lieu de 0 à 255. Mais ça n'empêche qu'il existe suffisamment de valeurs différentes pour stocker les 256 possibilités.
En hexa, il y a 256 nombres de 0x00 à 0xFF, il est donc possible de les stocker dans un byte. Seulement, dès qu'on dépasse 0x7F (la valeur 127,) on doit utiliser les bytes négatifs et on commence à moins bien comprendre comment ça marche.

Le plus simple est de prendre sa valeur int, et de la caster vers byte.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

byte byteValue = (byte)intValue;

Comment ça marche, c'est pas compliqué. Si prends prends un byte et que tu l'incrémentes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
byte byteValue = 0;
byteValue++;

byteValue passe à 1.

Continue comme ça indéfiniment, il se passe quoi ? byteValue arrive à 127, et ensuite ? C'est la valeur max d'un byte. Eh ben, ensuite, il boucle. Il passe à la valeur min, -128. Puis -127, puis -126 et ainsi de suite jusqu'à zéro, puis jusqu'à 127, et tout recommence. Les valeurs bouclent.

Les valeurs bouclent si on incrémente de 1, mais aussi si on incrémente de n'importe quoi.
Et donc, ta valeur 0xd4, c'est rien d'autre que 0x7F incrémenté de 0x55. Quand tu vas convertir le int vers byte, et que ça dépasse 0x7F, il va simplement boucler vers les valeurs négatives.

Voilà comment ça marche, mais bon, c'est juste la démonstration.
Tout ce qu'il faut faire, c'est un cast de int vers byte.

[304bl]

oui pour l'incrementation des variable signé j'avais compris le systeme, mais je me demander si lorsque j'envoie ce tableau de byte signé si java aller restituer sur le reseau les vrais valeurs.

Donc normalement java ou la librairie jpcap convertit par exemple ma valeur -71 par un protocole ou une syntaxe commune pour que au final la machine distante reçoive la vrai valeur et non -71, c'est bien ca ?

[tchize_]

Arrête de penser en décimal. -71, -100 ect, tout ça c'est une représentation du byte sous forme de chaine de caractère. La librairie pcap, elle, elle s'en fout complètement de comment java l'affiche. Elle recois un paquet de bits et elle l'envoie.

Que t'affiche 0xFF comme 255 ou -1, ça change rien au fait que ce sont huit bits à 1 11111111 et que ce sera ça qui sera traité.

Donc, ton 0xFF en int donne 00000000000000000000000011111111, convertit en byte, on ne conserve que les huit bits inférieurs, ce qui donne 11111111, ce qui sera envoyé par pcap si c'est le seul byte que tu lui fournis.

Bien sur, java lui quand il fait byte <-> chaine de caractère hexa, il n'autorise que [-0x80,0x7F] mais encore une fois, ça ne concerne que la réprésentation sous forme de chaine de caractère. Un byte, signé ou non, n'a que 8 bits et la mathématique d'addition/soustraction, accessoirement, est la même

[304bl]

c'est bon , ca marche !

le packet est envoyer sur le reseau et les valeur sont bien les memes que celui d'origine

par contre le packet d'un point de vu reseau n'est pas valide et m'annonce une erreur de checksum sur wireshark.

quelqu'un a t-il une idée d'ou cela pourrai venir ?

[thelvin]

Tu le lis d'une autre source, non ? Peut-être que ce packet n'est effectivement pas valide, avec une mauvaise valeur de checksum.
Il faudrait qu'on le voit...

[304bl]

oui effectivement je le récupère puis esseye de le re-injecter tel quel .

voici le packet UDP en question :

0x00, 0x24, 0xd4, 0xb1, 0x10, 0xa5, 0x00, 0x1f,
0xd0, 0x9a, 0x9b, 0xc7, 0x08, 0x00, 0x45, 0x00,
0x00, 0x4c, 0x02, 0x72, 0x40, 0x00, 0x80, 0x11,
0x00, 0x00, 0xc0, 0xa8, 0x01, 0x0a, 0x58, 0xbe,
0x1b, 0x94, 0xe1, 0x65, 0x93, 0x47, 0x00, 0x38,
0x36, 0x4e, 0x30, 0x58, 0xa1, 0x02, 0xaf, 0x55,
0x45, 0x1d, 0x83, 0x10, 0x42, 0x08, 0x22, 0x18,
0x00, 0x00, 0x00, 0x20, 0x10, 0x00, 0x00, 0x00,
0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x4a, 0x2f,
0xa4, 0x78, 0xb5, 0xd0, 0x07, 0x63, 0x9d, 0xe0,
0x37, 0x96, 0x0a, 0xea, 0x17, 0x00, 0x00, 0x00,
0x40, 0x03

mais je pense avoir un problème lors de la création du UDPPacket , sont constructeur a besoin du tableau de byte et de la longueur mais pour la longueur demander je ne trouve aucune indication , donc j'ai tenter de fournir la longueur total du packet ou celle de l’entête mais dans les 2 cas cela semble mal ce passé.