Je suis toujours sur le même bug décrit précédemment et ai réussi à identifier à peu près à quel endroit cela se passe. Il s'agit de la fonction gtk_file_chooser_dialog_new. Il semble qu'il y ait un problème avec pthread_create et cette fonction. A moins que cela soit pthread...
Le plus dur pour le moment n'est pas de trouver une solution à ce problème, le plus dur c'est de trouver et maîtriser des outils qui me permettraient d'aller plus vite dans mes recherches de bug. Si vous avez des noms d'application, n'hésitez pas car je sèche un peu...

Encore une nouvelle version de test. Cette fois-ci, il y a eu pas mal de modifications, notamment dans la gestion du thread de capture : je suis passé de pcap_next à pcap_next_ex dans la version linux.
Il y a pour le moment un gros bug que j'ai identifié que je n'arrive pas à corriger : Démarrez Ethergrouik, chargez un fichier de capture et continuez la capture. La capture se fait bien mais l'application semble figée ou du moins réagit beaucoup beaucoup moins vite... Je suis sur l'affaire

A force de lancer des scans ARP à répétition, j'ai réussi à faire tomber mon switch . Rien de grave car un A/M était suffisant. Cependant, il a fallu chercher l'origine du problème.
Le symptôme ? J'envoyais des trames ARP avec l'adresse MAC d'Ethergrouik et la réponse arrivait à une adresse MAC de destination (78:04:81:00:78:04) différente d'Ethergrouik ou de mon ordinateur. Pourtant la trame m'arrivait bien. La programmation n'est déjà pas évidente, alors si le matériel s'y met...
Il faut quand même reconnaître que ce switch (PEABIRD 16 ports) fonctionne très bien pour une utilisation de tous les jours.

Ai corrigé quelques bugs dans l'application ainsi que dans les fichiers de compilation.
Pour Ethergrouik => Makefile
Pour les plugins => install.sh

Je mets la version mac un peu de côté pour le moment car je n'ai toujours pas trouvé la solution Aussi, je préfère continuer le débuggage pour le moment pour pouvoir recommencer à améliorer l'ensemble.

Je viens de terminer la modification que je voulais réaliser sur la gestion des plugins. Cela a pris pas mal de temps car il a fallu reprendre tout le code. Une bonne chose de faite...
De même, j'ai enfin trouvé (du moins j'espère) le moyen de compiler les plugins proprement. J'ai ajouté un fichier README pour les commandes à passer sous linux.
Par contre, je suis un peu bloqué sous mac : gtk n'étant pas natif sous mac, je rencontre quelques petits problèmes avec l'éditeur de liens

Une nouvelle version pour les tests sous *X (XTest_0.0.9b)... Testé sous Ubuntu et Leopard.
Le plugin est bien pris en compte par Ubuntu, par contre Leopard ne le reconnaît pas correctement

PS : les 'fonctions' "make clean" et "make rmproper" fonctionnent

Actuellement, les listes chaînées sont indépendantes et surtout réinitialisés lors du démarrage d'une capture. Bien qu'Ethergrouik fonctionne correctement ainsi, je vais être obligé de faire quelques "grosses" modifications pour la prise en compte des plugins. Je sais lancer une instance de DLL lorsqu'une capture est en cours, mais comment faire lorsque l'utilisateur fait une RAZ de la capture en cours ? Lors de cette RAZ, tous les pointeurs de tête sont libérés. D'où la problématique suivante : comment faire pour informer une instance de DLL de cette modification et pour donner les nouvelles adresses des pointeurs ? Actuellement, Ethergrouik n'offre pas suffisamment de facilité pour l'emploi des DLL. Aussi je vais devoir changer mon fusil d'épaule...
Pour ce faire, je vais créer un pointeur qui contiendra tous les pointeurs de tête ainsi que les pointeurs de fin de certaines listes. Ce pointeur sera initialisé une seule fois, au démarrage de l'application et sera passé en paramètre au DLL. Ce pointeur ne pourra pas être réinitialisé, donc son adresse sera toujours valide ! Charge à la DLL de vérifier la valeur des éléments présents dans la structure de ce pointeur.
A suivre...

Je viens enfin de comprendre la combine pour le développement de plugins sous X.
La compilation de la 'dll' doit se faire avec l'argument "-shared" alors que la compilation du fichier qui exploitera la dll doit se faire avec l'argument "-ldl".
Ai modifié la version LinuxTest_0.0.9 en LinuxTest_0.0.9a. Ce fichier comprend Ethergrouik ainsi que la dll TCPSession.
Pour compiler cette dernière, placez vous dans le répertoire TCPSession et tapez make pour créer un fichier TCPSession.so.
Placez ce fichier dans le répertoire "plugins" d'Ethergrouik.

Rappel : la version TCPSession de ce fichier n'est que pour Linux pour le moment.

Salut !
Ai enfin terminé ma première version pour systèmes *X : Ethergrouik_IHM_LinuxTest_0.0.9.zip

Voici la marche à suivre :

- copiez et décompressez les sources d'Ethergrouik dans un répertoire.
- ouvrez un terminal et tapez : sudo apt-get install libxml2-dev libgtk2.0-dev libpcap0.8-dev
- enfin, tapez : make
Pour exécuter l'application, placez-vous dans le répertoire et tapez : sudo ./Ethergrouik

Les plugins et la gestion des outils ne fonctionnent pas dans cette version.

Je viens de trouver une autre bug : il se trouve dans la routine d'enregistrement d'un fichier XML. En effet, les balises NODE ont une propriété appelée "IP" au lieu de "ID" Quelle truffe !
La boulette était de taille, je viens de remettre une nouvelle version : la 0.0.8a.
Merci de votre compréhension !

La gestion du thread de capture est terminée et semble fonctionner correctement.
J'en ai profité pour corriger deux nouveaux bugs. Le premier concerne le rafraîchissement de l'onglet "Map" après la réinitialisation d'une capture et le second concerne l'arrêt du timer d'émission des trames sous *X.
Cela va peut-être vous paraître bizarre, mais le fait de compiler Ethergrouik dans différents environnements me permet de corriger pas mal de bugs. La raison est simple : GCC ne réagit pas du tout de la même façon

Le traceroute UDP est actuellement en test. Il sera, comme prévu, dans la version 0.0.9.
De même, j'ai continué mes petits travaux dans le monde X et malheureusement je suis bloqué par la gestion des threads : je découvre... Les compilations à partir de CodeBlocks sous Ubuntu 7.10 et à partir d'un fichier Makefile sous Leopard se sont avérées concluantes, moyennant quelques petites corrections . La fonction "capture de trames" a été temporairement inhibée le temps de trouver une solution à mon problème. Si vous êtes intéressés par le portage de l'application sous *X, faites le moi savoir !

La version 0.0.8 est disponible dès à présent dans l'onglet "téléchargement".

Have a good grouik !