Dans mes bras :D ;)
PS : je sais vraiment pas où les nouveaux Acédémiciens ont été chercher la "nouvelle" orthographe... :roll:
Version imprimable
oui je sais, et si tu vas sur le site de l'Académie, maintenant ils mettent que c'est "au temps", avec une explication torturée que c'est un "juron" d'un militaire du temps de Napoléon...
Mais tous les dicos que j'ai regardé (y compris les Littré de 1958 ou le Premier Larrousse de 1868) mettent "Autant", ce qui a quand même nettement plus de sens : "autant de honte", "autant de critique", "autant de reproches"..
Nulle part dans "temps" n'est fait mention de "au temps"..
Alors je suis d'accord que le Français soit une langue vivante, mais pas à n'importe quel prix ;)
(comme "la sérénitude" etc etc..)
Déjà que l'accord des participes au féminin disparaît...
Ba directement ca va être un peu dur: la couche que je traite se trouve au dessus de IP et TCP (et encore d'une autre que j'ai déjà décodé). Et puis faire un plugin directement pour Wireshark est, je pense, plus simple, parce que:
- je ne me vois pas faire moi-même une interface graphique, surtout s'il y en a déjà une de bien de déjà faite.
- si j'ai bien compris, c'est Wireshark qui s'occupe du décodage des trames TCP et IP, et ca j'ai pas franchement envie de le faire (déjà que je galère en ce moment pour faire la doc de mon premier plugin... si je dois en plus faire la doc pour ca ^^ )
- parce que Wireshark s'occupe tout seul de réassembler les trames TCP que celui-ci découpe mais ne recolle pas (génial le protocole!). Et ca, je n'ai vraiment pas non plus envie de le faire!
- les gens avec qui je travaillent lancent Wireshark, et voilà quoi ^^ ils veulent que ce soit là!
Sinon merci pour text2pcap, je l'ai découvert hier alors que ca fait un mois que je travaille sur Wireshark... mieux vaut tard que jamais!
Au fait, tu as déjà travaillé avec Wireshark, vu tes connaissances? Tu sais comment ca se passe pour "empiler" des couches? Parce que là je ne sais pas trop comment il va détecter quel plugin est à utiliser en premier, et l'autre en second, les deux étant configurés pour le même port...
OK.
Ton message précédent est ambigu, il sous-entendait que tu avais un programme de test autonome qui faisait déjà 100% du boulot... Affichage inclus, donc.
Si c'est en mode analyse de réseau, effectivement, il y a un peu de boulot. Si c'est en mode réception sur un PC, c'est à dire espionnage de ce que l'application reçoit, c'est alors déjà fait par la pile TCP/IP de l'OS.
Normal, ça, c'est dans les suivis de conversation. Wireshark fonctionne comme la librairie PCAP : au niveau trame Ethernet.
Il y a plusieurs autres outils dans ce genre, dans le répertoire Wireshark. Au cas où...
Plutôt avec la librairie PCAP, en fait.
Côté tripaille, je ne sais plus. Côté "réalité", c'est lié aux données de la couche précédente, chaque couche permettant de dire quelle est la couche supérieure.
Il ne peut pas s'il n'y a pas de discriminant.
Tu peux ruser en ajoutant un faux protocole entre TCP et la suite, qui décrit juste l'entête commun des deux protocoles, et permet d'aiguiller ensuite sur le décodage spécifique.
Mais ça demande à ce que le protocole initial aie été bien conçu, c'est hélas rarement le cas...
En effet! En fait il y a affichage et affichage (comment ca je ne suis pas clair!). Quand je disais qu'il s'occupe de l'affichage, j'entendais par là qu'il renvoyait à la console des lignes de texte formatées, du genre:Citation:
Ton message précédent est ambigu, il sous-entendait que tu avais un programme de test autonome qui faisait déjà 100% du boulot... Affichage inclus, donc.
(bit de début) type_de_message type_construit[num_du type] L: longueur / type de données : données_traduites
genre ca:
Mais cela ne signifiait pas que j'utilisais une interface graphique ;)Citation:
(***5) | UC P[*26] L:**8 / Char string: JPL_TEST
(**15) | UC P[*26] L:**4 / Char string: RF11
désolé de m'être si mal exprimé!
Le principe est de brancher un ordinateur au milieu et d'écouter ce qui transite. Après en pratique cela se fait souvent sur le PC qui reçoit, mais je crois que ca c'est surtout pour les tests. Donc c'est la première solution qui s'impose...Citation:
Si c'est en mode analyse de réseau, effectivement, il y a un peu de boulot. Si c'est en mode réception sur un PC, c'est à dire espionnage de ce que l'application reçoit, c'est alors déjà fait par la pile TCP/IP de l'OS.
Sinon pour vous expliquer l'histoire des protocoles, le plus simple est un schéma: http://imagik.fr/view-rl/93396 (vous pouvez au passage admirer mes talents d'artiste ^^)
j'ai donc décodé jusqu'à la couche ISP, et la je dois décoder la couche ASN.1 (qui ressemble apparemment à du XML, mais vu que je n'en ai jamais fait, je peux pas dire). L'ISP sert juste à transmettre des paramètres de connexion, faire des heartbeat message, et accessoirement, transmettre les données. Donc à ce niveau là c'est clair, je sais dans quel cas on utilise la seconde couche.
Sinon par discriminant, tu entends quelque chose dans le plugin qui dit quel autre plugin peut être utilisé pour la couche suivante?
Si oui, ca se dit comment en anglais? J'ai cherché sur Google, et j'ai pas trouvé grand chose d'intéressant à ce niveau, donc si tu avais un tuto sous la main, ca ne serait pas de refus ;)
Quel dissector, en fait. Mais oui, c'est ça.
Pas de tuto, ni de liens : je m'occupe en général du bas niveau (c'est à dire le protocole lui-même), pas de son analyse. Je n'ai donc que des informations fragmentaires à ce niveau.
Essaie avec "wireshark protocol chain filter", peut-être...