Discussion :

[funtix]

Salut
J'utilise la winpcap pour un projet.
Je me rends compte que les perfs sont desastreuses. Apres analyse, j'ai compris d'ou venait le probleme. Il est finalement simple, il y a x fois plus de frames à capturer que ce que je peux traiter. La fonction pcap_next_ex retourne a mon appli un packet de données. Mais il s'agit pas du dernier. Celui emit au moment de la capture. Il s'agit d'un packet bufferisé au niveau du driver winpcap. Je pense que la winpcap utilise FIFO en interne. J'arriverais a resoudre mon probleme si je pouvais limiter la taille de cette FIFO quitte a perdre des trames.
Mais je n'ai pas trouvé de fonction qui faisait cela. Existe t elle? On doit bien pouvoir ignorer une liste de paquet pour ne recuperer que le dernier (peut etre avec packet32.dll).
Sinon je pensais à un truc un peu beurk: faire un while sur le pcap_next_ex jusqu'a ce que j'atteigne le dernier paquet.

Des avis, des infos... je suis preneur. Merci.

[Aramis]

Bonjour,

est ce que WinPCap supporte les Berkley Packet Filter (comme dans Ethereal)? Si c'est le cas vous pourriez passer quelque filtres en parametre afin de limiter le type de packet que vous voulez traiter.

Par exemple:

Code :

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

1
2
host 192.168.0.1 and host 192.168.0.3

Bien entendu, ce genre de filtre peut etre combiner avec un filtre pour la couche transport et etc.

Pour terminer, il me semble que l'archive de developpement de WinPCap est livre avec une doc et des tutoriels, n'y a t-il pas dans celle-ci un truc sur comment capturer beaucoup de packet? ou du moins comment s'en occuper de maniere efficace. Cependant, ne vous faites pas d'illusion en ce qui concerne les performances, les logiciels de capture ont du mal a tenir le coup de tout facon, et ce ci meme sur un reseaux 10mbps.

References :
[1] Yan, Hong & Frenz, Ryan "An adaptive and scalable architecture for rule-based real-time analysis of network traffic"
[2] Antonatos, Spyros Anagnostakis, Kostas G. Markatos, Evangelos P. & Polychronakis, M. "ExB: Exclusion-based signature matching for intrusion detection"
[3] Antonatos, Spyros Anagnostakis, Kostas G. & Markatos, Evangelos P. "Generating realistic workloads for network intrusion detection systems"

et surement bien d'autres encore


Bon courage,

Ar@mi$

[funtix]

Bonsoir
la version windows de ethereal utilise la winpcap. Les regles de filtrage BPF dont tu parles dans ethereal sont directement passés au driver winpcap.
J'utilise egalement un filtre. Mais cela ne suffit pas meme si cela permet d'eliminer deja beaucoup de paquets.

Pour ecrire mon appli je me suis basé sur les exemples fournis avec la winpcap. Mais il reste assez simple et n'explore pas tous les services de la winpcap.

Je pense qu'il existe une solution mais avec les services plus bas niveau de la packet.dll. Et la il existe bien moins de docs.

Pour arriver a mes fins, j'ai itéré sur le service pcap_next jusqu'a que celui ci me retourne qu'il n'ait plus de paquets disponibles. Ca marche mais ce n'est pas optimal à mon avis. Vu les services bas niveau de la packet.dll, on doit pouvoir configurer le driver de capture de maniere beaucoup plus fines.

Je vais essayer de jeter un coup d'oeil sur les bouquins que tu indiques...
merci de ta participation.

[Aramis]

Re,

les references que j'ai donne ne sont pas des livres mais des articles de recherche. Le but de mon intervention est de vous montrer que les performances dans le domaine de la capture de trafic reseaux sont problematiques. Meme des logiciels reputes comme Snort ont du mal (cf. article n 1), par consequent vos chances de creer un systeme de capture aussi performant sont reduites Encore une fois, c'est une histoire de point de vue bien entendu.

Quels sont les resultats que vous obtenez en ce moment? Pouvez capturer 10Mbps sur un reseaux tournant a 100Mbps sans perdre un seul packet par exemple?

--- pause ---

hmm, je viens de regarder les resultats que nous avons publie en Juin de cette annee et a 1mbps nous avons constate que Snort pert 69% des packets

Ar@mi$

[funtix]

Salut
J'ai laissé tomber les investigations qui visaient a trouver un service bas niveau pour configurer la taille de la FIFO. Manque de temps... Dans l'état actuel (avec la solution décrite dans le post précédent) ca fonctionne très bien puisque je ne perds aucun paquet et les paquets sont traités en temps réel et n'ont pas le temps d'être bufferisés dans la FIFO du driver.

Le problème n'était pas du a un traffic trop important mais par une mauvaise compréhension du probleme (je recevais en réalité plusieurs paquets alors que moi je pensais n'en recevoir qu'un seul et donc n'en traité qu'un d'ou l'empilement des paquets et un retard entre le paquet traité et ceux transitant) et de la fonction pcap_next (qui retourne qu'un seul paquet meme si le driver lui en a capturé plusieurs d'un seul coup).

Je sais pas si c'est tres clair mais bon ...