Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1077 connectés 

 


Dernière réponse
Sujet : Problème de décodage de trames (pour les pros d'Ethereal ?)
II-J_U_L-II Pour ceux que ça intéresse, j'ai finalement trouvé la solution. Elle était sur le site de libpcap, format natif des fichier de logs ethereal. Ce format structure la capture de la manière suivante :
 
En-tête Globale du fichier - En-tête de Trame1 - Trame1 - En-tête de Trame2 - Trame2 - En-tête de...
 
L'en-tête globale du fichier de capture est codée sur 24 octets; elle contient 7 champs, dont la version du format de fichier, taille max de la capture,... rien de très interessant.
 
L'en-tête de chaque trame, contient 4 champs, tous codés sur 4 octets. On y retrouve la date de capture du paquet (utiliser ctime() pour la récupérer, la taille du paquet,...
 
A noter que les champs de ces en-tête libpcap se parcourent bien de gauche à droite, contrairement à leurs octets qui se lisent en sens inverse.
 
Plus de détails sur : http://wiki.ethereal.com/Development/LibpcapFileFormat, pour la Global Header et la Record (Packet) Header.
 
Bonne journée à vous !
 
 
Jul

Votre réponse
Nom d'utilisateur    Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !
Le ton de votre message                        
                       
Votre réponse


[b][i][u][strike][spoiler][fixed][cpp][url][email][img][*]   
 
   [quote]
 

Options

 
Vous avez perdu votre mot de passe ?


Vue Rapide de la discussion
II-J_U_L-II Pour ceux que ça intéresse, j'ai finalement trouvé la solution. Elle était sur le site de libpcap, format natif des fichier de logs ethereal. Ce format structure la capture de la manière suivante :
 
En-tête Globale du fichier - En-tête de Trame1 - Trame1 - En-tête de Trame2 - Trame2 - En-tête de...
 
L'en-tête globale du fichier de capture est codée sur 24 octets; elle contient 7 champs, dont la version du format de fichier, taille max de la capture,... rien de très interessant.
 
L'en-tête de chaque trame, contient 4 champs, tous codés sur 4 octets. On y retrouve la date de capture du paquet (utiliser ctime() pour la récupérer, la taille du paquet,...
 
A noter que les champs de ces en-tête libpcap se parcourent bien de gauche à droite, contrairement à leurs octets qui se lisent en sens inverse.
 
Plus de détails sur : http://wiki.ethereal.com/Development/LibpcapFileFormat, pour la Global Header et la Record (Packet) Header.
 
Bonne journée à vous !
 
 
Jul
II-J_U_L-II Bonjour à tous,
 
 
Je développe actuellement une petite appli en c qui récupère et décode des trames générées par Ethereal pour mesurer les temps de réponse d'un applicatif (au niveau TCP). J'utilise donc les fichiers de captures générés par le sniffer pour le décodage et la récupération des infos dans une base MySQL.  
 
Mon problème est le suivant :  
 
Les fichiers générés par Ethereal (au format natif, obligatoire pour la récupération en temps réel) contiennent le code hexa du champs Frame (info sur le numéro de la trame, date, heure, taille totale de la trame, ...), premier champs lisible dans la fenêtre graphique de décodage du logiciel. Or le code hexa, dans cette fenêtre, ne commence qu'à partir de protocole de niveau 2 (trame Ethernet). Lorsqu'on clique sur un sous-champs du champs Frame, on n'obtient pas le code hexa correspondant, or ce code est bien présent dans le fichier de capture.
 
Quelqu'un saurait-il comment sont codés les éléments de ce champs ?
 
Merci beaucoup pour votre aide !
 
 
Jul

Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR