["Ronnie Sahlberg" <sahlberg@xxxxxxxxxxxxxxxx>]

Hi Serigo,


From: "Guy Harris"
To: "sergio morant"
Sent: Wednesday, September 18, 2002 8:44 AM
Subject: [Ethereal-dev] Re: NEW MODULES FOR TRAFFIC ANALYSIS


> On Wed, Aug 28, 2002 at 12:12:23PM +0200, sergio morant wrote:
> >   Hello,
> > I'm a student at the university of ENST-Bretagne ( FRANCE )

> > First of all I want to introduce what are the objectives for those
> > modules: The main idea is to be able to evaluate the kind of traffic
> > that is passing through the router, the machines that generates it, and
> > how the traffic variates along the capture period using  all this
> > information to build a rule set for COPS. The intention it  is also that
> > the analysis can be scheduled using Cron or another scheduler daemon.
> > Since all the analysis results are flushed to a text file I have written
> > some functions that automatically generates the strings  for the file
> > name based upon the timestamp of the first frame captured.

> > Right now I'm trying to make another module that can send messages to a
> > COPS client (PEP) installed on the same machine but at this moment it
> > only shows messages on the screen because I have to see which
> > implementation of COPS I will use to build the interface between the
> > module and the COPS client application. I don't know If there is some
> > body working on the same direction or if you have tryed something like
> > that or simply if you know a good implementation for COPS because I have
> > seem that there is not many under GNU. The files are :
> > flow_monitor.c  and flow_monitor.h

This all sounds interesting.
I assume what the extensions are really meant to do is basically
monitor for certain packets matching certain criterias and then generate a
report
with either number of packets or number of bytes matching tat criteria in
each time interval.
Then that data MIGHT be parsed and used by something like COPS or something
else.
Basically collecting statistics and presenting something like :
========================================
Measurement interval: 300SECS
Measured unit: BYTES
TYPE 1: (nfs && ip.addr==1.2.3.4)
TYPE 2: (nfs && ip.addr==1.2.3.5)
...
------------------------------------------------------------
TIME                   TYPE 1       TYPE 2     ...
   0- 300SECS :    1023            0
 300-600SECS:     5732           101
...
=========================================

Ok, that sounds like something really useful.

However, I am not happy with a solution that only provides data specially
formatted
to only be used by a very narrow and specific application such as COPS if it
is going into the normal cvs/distro.
So, it has to be formatted and implemented in such a way so that it is
generic and can
be used for other uses as well.
This does not prevent the implementation from presenting the data in such a
way that parsing is easy making it easy to, by using a script or tool
EXTERNAL to ethereal, massage the data for consumption by the COPS tool.


For things like this, there is now no need to mess directly with the
dissectors themself, polluting them.
Please study the reasonably new files doc/README.tapping and the example of
tapping for tethereal in tap-rpcstat.c.
Tapping provides a way to enable extensions such as yours a method to get
callbacks for certain pakcets matching certain criterias so statistics can
be collected. It is implemented in such a way that you will never need to
place extension specific code in the dissector itself. This is a big plus.


Maybe something like the example table above is what your extension needs,
by implementing it as a tap extensions generating such a table as above you
acheive two things:
1, your specific application gets a method to extract the data it is
interested in. (after som scropt parsing of the output table)
2, it would be generic enough to be able to be used for any user for any
purpose.


May I even suggest a commandline parameter to activate this feature for
tethereal
-z traffic,300,bytes,(nfs && ip.addr==1.2.3.4),(nfs && ip.addr==1.2.3.5)
traffic: would enable this specific feature.
300: would be the time intervals as 300seconds per mesurement unit
bytes: present output as total number of bytes instead of 'packets': number
of packets.


I hope something like this would provide the data you are interested in for
your application. Please correct me if i ompletely misunderstood your
requirements.

---
I could implement this kind of extension for tethereal myself but would VERY
MUCH prefer if someone else did it. Preferably a non-ethereal hacker.
See it as a test to see if the API is easy to use and non ethereal hackers
can use it.
If someone else with little experience of ethereal could hack together a
clean implementation of a reasonably advanced feature such as described
above, then it would prove to me that the designed API has been successful.


Hint hint:
Of course, later implementing the same feature but for Gtk/Gtk2 would be
VERY useful.


best regards
    ronnie sahlberg