D�coupage trame ethernet c++

Bonjour � tous,

Je viens vers ici dans l'espoir d'une r�ponse pour me guider.

En effet, dans le but de mon apprentissage, je dois r�cup�rer une trame Ethernet, la stocker et l'�crire dans un fichier.

Cependant, pour l'�criture, j'�cris ma trame ethernet en hexa, ligne par ligne, dans un stringstream. Mais je n'arrive pas � d�couper celle-ci, car il faut que j'ins�re un espace apr�s chaque "mots" de n octets (1 octets = 4 caract�res). Dans cette trame, j'ai donc 52 mots. Les 7 premiers mots sont sur 4 octets chacun, les 36 suivant sont sur 2 octets chacun, puis 1 mot sur 52 octets (bourrage ou r�serve pour futur utilisation) et enfin, j'ai un dernier mot sur 2 octets et les 8 derniers mots sont sur 4 (1 mot), 16 (1 mots) et 2 octets. Au total ma trame fait 188 octets.

Je ne sais donc pas comment r�cup�rer mon stringstream, puis parcourir chaque ligne en modifiant chacune d'entre elle pour lui donner le bon format.

J�esp�re avoir �t� assez pr�cis.

Dans l'espoir d'avoir une r�ponse,

En vous remerciant d'avance.

salut au besoin se documenter sur les champs de bit
https://en.wikipedia.org/wiki/Bit_field
Mais sinon rien qu'avec les fonctionnalit�s de std::string �a suffit largement.

Citation:

Mais je n'arrive pas � d�couper celle-ci, car il faut que j'ins�re un espace apr�s chaque "mots" de n octets (1 octets = 4 caract�res).

O� est le probl�me ? Avec std::string c'est faisable.
Il faudrait nous donner du code

Salut,

j'ai l'impression que ton principal probl�me est de faire une s�rieuse soupe entre les notions de caract�res et de valeurs d'une part et entre les notions de "d�cimale" et de "hexad�cimale" d'autre part.

Car, pour ce qui est de la premi�re partie, il faut savoir que '1' (le caract�re, le "glyphe" qui repr�sente le chiffre 1) ... n'est pas �gal � la valeur num�rique 1.

Le "glyphe" qui repr�sente le chiffre 1, on le retrouve � la position 49 de la table ASCII, qui est la table couramment utilis�e pour permettre l'affichage � l'�cran (ou l'inscription dans un fichier). Cela signifie que si tu venais � �crire un code proche de std::cout<< (char)49 (ce code est horrible, mais il sert tellement bien mon exemple :D ) tu verrais apparaitre ... le chiffre 1.

Pourquoi :question: parce que ce code demande explicitement � l'ordinateur d'afficher le caract�re auquel la valeur (num�rique) 49 est associ�e, et que l'ordinateur va donc aller voir dans la table de caract�res qu'il utilise (la table ASCII) le glyphe qui se trouve... � la position 49 et qui n'est rien d'autre que le glyphe qui repr�sente le chiffre 1.

D'un autre cot�,les notions de "d�cimale" et de "hexad�cimale" sont ce que l'on appelle des "bases de calcul". La base d�cimale, c'est celle que nous utilisons "tous les jours", celle qui va utiliser les chiffre de 0 � 9 pour faire nos calculs courrents: (3 + 4) * 5 = 35.

La base hexad�cimale, quant � elle, ne va pas utiliser dix chiffres, mais ... 16. Bien sur, on n'a pas de "chiffre particulier" pour repr�senter les valeurs comprises entre 11 et 15 inclue. On va donc prendre les lettres qui existent d�j�: A, B, C, D, E et F.

L'hexad�cimal a ceci d'int�ressant qu'il "s'aligne" parfaitement avec le nombre de valeurs susceptibles d'�tre repr�sent�e lorsque l'on a quatre "points de contact" o� le courant peut passer ou non (ce qui est --grosso modo -- la d�finition d'un bit). En effet, si on prend quatre bits ensemble, on dispose de 2⁴ = ... 16 possibilit�s, ce qui correspond exactement au nombre de possibilit�s que nous donnent nos dix chiffres "classiques" (0,1,2,3,4,5,6,7,8 et 9) auxquelles on a ajout� les six premi�re lettres de l'alphabet.

Pour faire la diff�rence entre la notation (la "repr�sentation" d'une valeur � l'�cran ou dans un fichier ) d�cimale et la notation hexad�cimale, on a "simplement" d�cid� (par convention) de rajouter le pr�fixe 0x pour indiquer clairement que nous utilisons la repr�sentation hexad�cimale.

Cependant, nous pourrons sans aucun probl�me repr�senter exactement les m�mes valeurs num�riques! Il y a parfaite �quivalence de valeur entre les diff�rentes bases de calcul. Un peu comme le terme "arbre" en Fran�ais: un anglais parlera de "tree" et un n�eralandophone parlera de "boom", et pourtant, ils parleront tous les trois de la m�me chose ;)

h� bien, ici, c'est pareil: si tu veux afficher la valeur 15 en d�cimale, tu affichera "15", mais si tu veux l'afficher sous la forme hexad�cimale, tu l'affichera sous la forme de "0x0F" voire, si tu pars du principe et de la convention que l'affichage se fait ** forc�ment ** en hexad�cimale, sous la forme de F.

Ainsi, si tu veux afficher la valeur (d�cimale) 103 en hexad�cimale, tu l'affichera sous la forme de (0x)63.

On pourrait m�me s'amuser � trouver le moyen de "convertir" une valeur d�cimale en valeur hexad�cimale et vice-versa. L'algorithme � mettre en place est particuli�rement simple. Mais bon, ce n'est pas la chose la plus importante � faire, car, du fait m�me que l'ordinateur ne connait que le binaire (le courant passe ou ne passe pas � un endroit donn�), il va "naturellement" convertir nos valeurs d�cimales en binaire, ce qui le mettra dans une excellente position pour manipuler les valeurs num�riques sous leur forme hexad�cimale ;)

Bon, tout cela, c'est un peu la th�orie, et j'esp�re t'en avoir "assez dit" que pour te permettre de comprendre le principe. Car il y a une chose encore plus importante � comprendre et que tu auras beaucoup plus facile � comprendre cette chose si tu as compris la diff�rence entre binaire, d�cimale et hexad�cimale et la diff�rence entre la notion de caract�re et celle de valeur num�rique.

Commen�ons par le plus simple, et pourtant sans doute la chose la plus "contre intuitive" parmi toutes choses contre intuitives que l'on peut envisager: les donn�es que l'on manipule � partir de l'ordinateur ne signifie absolument rien pour lui.

Que nous manipulions des couleurs, des sons, des images ou m�me les instructions que l'on va demander � l'ordinateur d'ex�cuter, l'ordinateur, lui, ne verra jamais qu'une seule et unique chose: une succession plus ou moins grande de points o� il pourra aller tester si le courant passe (ou non) � un moment donn�.

C'est parce que nous (les humains qui utilisons l'ordinateur), nous allons d�cider d'interpr�ter cette succession plus ou moins grande de bits d'une mani�re bien particuli�re que nous serons en mesure de demander � l'ordinateur d'ex�cuter "tel ensemble d'instructions", destin�es � la manipulation de "tel type bien particulier de donn�e" au lieu d'effectuer "tel autre ensemble d'instructions" qui serait lui adapt� � la manipulation de "tel autre type de donn�e.

Mais il faut comprendre que cette notion de "type de donn�e particulier", elle n'a vraiment de l'int�r�t que pour nous (les humains qui utilisons l'ordinateur).

Alors, j'esp�re non seulement t'avoir convaincu par cette explication, mais surtout que tu as compris l'id�e que j'essayais de faire passer, car, si c'est le cas, le point suivant te paraitra parfaitement logique :D

Il faut savoir que la mani�re dont nous allons afficher les donn�es n'est au final que la repr�sentation des donn�es que l'on va nous donner (� nous, humains qui utilisons l'ordinateur) dans l'espoir que nous soyons en mesure de ... les interpr�ter correctement le plus facilement possible.

Mais revenons � ta description de la trame ethernet. Tu nous dis

Citation:

Cependant, pour l'�criture, j'�cris ma trame ethernet en hexa, ligne par ligne, dans un stringstream. Mais je n'arrive pas � d�couper celle-ci, car il faut que j'ins�re un espace apr�s chaque "mots" de n octets (1 octets = 4 caract�res). Dans cette trame, j'ai donc 52 mots. Les 7 premiers mots sont sur 4 octets chacun, les 36 suivant sont sur 2 octets chacun, puis 1 mot sur 52 octets (bourrage ou r�serve pour futur utilisation) et enfin, j'ai un dernier mot sur 2 octets et les 8 derniers mots sont sur 4 (1 mot), 16 (1 mots) et 2 octets. Au total ma trame fait 188 octets.

Oh l� l�... tu es occup� � nous faire une fameuse soupe l� :aie:

Oublions donc un instant que tu veux repr�senter ta trame internet d'une mani�re "compr�hensible pour toi" � l'�cran, et posons nous une question simple: combien d'octets la trame ethernet que tu obtiens fait elle :question:

Si j'ai bien compris ton explication -- et que j'ai bien compt� -- tu re�ois 152 octets � chaque trame, est-ce bien cela :question:

H� bien, dis toi que la repr�sentation la plus proche de la r�alit� que nous pourrions nous faire de la repr�sentation de cette trame de 152 octets en m�moire, ce serait ... une succession de 152*8 = 1024 "1" et "0" qui se suivent.

Mais cette repr�sentation est d�j� une certaine forme d'interpr�tation, car le "1" repr�senterait un bit par lequel le courant passe, et le "0" repr�senterait un bit par lequel le courant ne passe pas.

Et bien sur, cette repr�sentation aurait beau �tre la plus proche de la mani�re dont ta trame est repr�sent�e en m�moire, ce n'est certainement pas la repr�sentation qui nous permettrait -- � nous "pauvres humains" -- de comprendre le contenu de la trame le plus facilement ;)

Essayons donc de "compacter" un peu cet affichage. Pour ce faire, nous allons travailler en deux temps:

D'abord, nous "regroupons" tous les bits par "groupe de 8", ce qui nous permet d'obtenir ce que l'on appelle "des octets". Nous obtenons donc ... 152 groupes de 8 bits, mais l�, je ne fais que revenir en arri�re.

Ensuite, nous d�cidons d'utiliser la notation hexad�cimale pour repr�senter la valeur de chaque octet et, pour �viter les probl�mes qui seraient �ventuellement li�s au fait qu'un octet puisse repr�senter une valeur num�rique inf�rieure � 16, nous d�cidons d'utiliser syst�matiquement un "symbole" (les chiffres et les lettres) par "demi octet" (par groupe de 4 bits).

De cette mani�re, que si nous avons un octet dont la valeur num�rique �quivaut � 15, nous afficherons 0F au lieu d'afficher simplement F. Mais ca, c'est juste une convention que l'on choisi d'appliquer "pour notre propre facilit�", car elle va nous permettre de voir directement que nous avons trois octets (valant chacun 15) avec un affichage proche de0F0F0F alors que, autrement l'affichage FFF nous laissait nous poser la question de la mani�re dont il fallait l'interpr�ter: est-ce

3 octets valant chacun 15
un octet valant 255 suivi d'un octet valan 15 ou
un octet valant 15 suivi d'un octet valant 255

Parce que les trois possibilit�s auraient �t� "plausibles" et que chacune d'elle aurait eu une signification diff�rente au niveau de la trame.

NOTA: Nous n'ayons choisi l'affichage sous une forme hexad�cimale finalement que parce que c'est la repr�sentation la plus "compacte" et pourtant la "plus facile � interpr�ter" dont nous disposions.

Nous nous retrouvons en effet avec l'affichage de 254 "glyphes", que nous pourrions "grouper par 2", alors que si on avait choisi d'afficher ces valeurs sous une forme d�cimale, nous aurions eu besoin de ... trois "glyphes" par octet, vu qu'il aurait fallu repr�senter des valeur allant de 0 � ... 255 et que nous aurions de toutes fa�ons �t� confront�s � un probl�me tout � fait similaire (mais sur trois glyphes au lieu de deux) � celui que je viens d'expliquer.

Une derni�re solution aurait d'ailleurs pu nous traverser l'esprit, car nous savons maintenant que un octet (un groupe de huit bits cons�cutifs) permet de repr�senter "n'importe quelle place valide" dans la table ASCII. Il n'y aurait donc qu'un pas � franchir pour se dire que "ce serait encore plus compact et donc plus compr�hensible si nous demandions simplement d'afficher le glyphe associ� � chaque valeur dans la table ASCII", n'est-ce pas :question:

H� bien non... Et pour plusieurs raisons:

D'abord, les glyphes associ�s aux valeurs comprises entre 128 et 255 ne sont pas les m�me partout: il n'y a vraiment que pour les valeurs comprises entre 0 et 127 (inclus) qui ne changeront jamais.
Ensuite parce qu'il y a une s�rie de caract�res qui n'ont pas vocation � �tre affich�s. Ce sont les caract�res associ�s aux valeur comprises entre 0 et 31 (inclus) ainsi que le caract�re associ� � la valeur 127.
Enfin, et surtout, parce que ces caract�res qui "n'ont pas vocation � �tre affich�s" ont chacun une signification particuli�re pour le syst�me qui s'occupe de l'affichage justement. Si on essaye de les afficher nous m�me, on risque d'avoir des r�sultat ... plut�t surprenants ;)

(essaye de compiler et d'ex�cuter -- apr�s avoir mis le casque et pouss� le volume � fond -- un code contenant std::cout<<(char)7; pour t'en convaincre... C'est le plus marrant bien que sans grand danger ;) )

Mais revenons � nos moutons: nous avons donc potentiellement 152 groupes de 2 glyphes qui repr�sentent l'ensemble des octets de la trame sans que nous n'ayons cherch� � les interpr�ter d'une quelconque mani�re.

La question qu'il serait sans doute int�ressant de se poser est : cette repr�sentation est-elle "suffisamment facile � interpr�ter" par celui qui devra l'interpr�ter :question:

Si la r�ponse est oui, sinc�rement, je ne vois pas trop pourquoi nous voudrions nous faire du mal en essayant de faire plus complexe que cela ;)

Et, pour �tre tout � fait honn�te, je dirais volontiers que nous devrions nous arr�ter l�, car on a d�j� fait le plus gros: on a r�cup�r� la trame �thernet et on en donne une repr�sentation "suffisamment compacte" que pour pouvoir �tre interpr�t�e au besoin. Avoue que c'est d�j� pas si mal, non?

D'autant plus que, si tu d�cide d'analyser cette trame "plus en profondeur", si tu d�cide de t'int�resser � la signification de chaque (groupe d') octet(s) de la trame, tu seras sans doute int�ress� par le fait d'afficher ta trame dans quelque chose "d'un peu plus maniable" que ta console de commande.

En nous arr�tant ici, nous nous arr�terions en fait "juste avant" de commencer � appliquer des changements susceptibles d'interf�rer avec les outils utilis�s pour l'interpr�tation de la trame.

Bien sur, nous pourrions d�cider de s�parer les diff�rents groupes d'octets que ta trame contient d'un tas de mani�re diff�rentes. J'esp�re que tu auras d�sormais compris que cela ne ferait que changer ... la repr�sentation de ta trame que tu propose � l'utilisateur. Et rien ne serait impossible � d�faire en cas de besoin (par exemple, si l'utilisateur souhaite utiliser un outil "plus sympathique" pour analyser la trame).

La question est: est ce que cela vaut vraiment la peine :question: ne pourrait on pas suivre le principe "wait and see" des anglais, et nous dire que nous pourrions "tout aussi bien" attendre d'avoir la certitude que l'utilisateur veut utiliser la sortie console pour analyser la trame avant de lancer la transformation qui lui permettra de le faire de mani�re sympa :question:

Cette question, moi, je la laisse en suspend pour l'instant, car c'est � toi que revient la d�cision ;) Mais, au moins, si tu as compris l'ensemble de ce roman (et sinon, n'h�site pas � le relire plusieurs fois ou meme � poser des questions suppl�mentaires :D ) tu ne devrais plus t'embrumer le cerveau avec des questions qui n'en valent pas vraiment la peine ;)