ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: Re: [Ethereal-dev] Proposal for replacement of tap_rtp.c

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Lars Ruoff" <lars.ruoff@xxxxxxxxxxxxxxxxxx>
Date: Mon, 25 Aug 2003 09:33:24 +0200
I compiled with GTK 1.3 (for Win32)
Files have to be added to /gtk-directory.
Joined is a diff -c of Makefile.nmake in /gtk
Other makefiles should go accordingly (?).

Lars.

----- Original Message ----- 
From: "Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>
To: "Lars Ruoff" <lars.ruoff@xxxxxxxxxxxxxxxxxx>; "Ethereal-Dev"
<Ethereal-dev@xxxxxxxxxxxx>
Sent: Saturday, August 23, 2003 6:55 AM
Subject: Re: [Ethereal-dev] Proposal for replacement of tap_rtp.c


> The code does not compile neither for Gtk1 or for Gtk2
>
> Gtk1 complains about missing definitions for g_strl...
> Gtk2 complains about a lot of unused variables and fails shortly
thereafter.
>
>
> Please provide a real  diff -c  diff that also updates the appropriate
> makefiles (Makefile.am  Makefile.nmake)
> and updates to ethereal.pod.template  documentation when it compiles.
>
>
>
> ----- Original Message -----
> From: "Lars Ruoff"
> Sent: Saturday, August 23, 2003 1:10 AM
> Subject: [Ethereal-dev] Proposal for replacement of tap_rtp.c
>
>
> >
> > Hi,
> >
> > i present a new version of the RTP analysis module for the GUI version
of
> > Ethereal.
> > It completely replaces Miha Jemec's "tap_rtp" (accessible via
> > Tools/Statistics/RTP Analysis...).
> >
> > For the moment, there is no real extension of features (apart from the
> > streams list, which i will explain later),
> > but the main difference lies in the code, which i completely reviewed
and
> > refactured:
> > - It is much clearer now and easier to read (Sorry Miha, but you will
> agree
> > on that the old one was really a mess in some places).
> >   Now there is a strict separation between logic- and GUI- stuff.
> > - The code is more modular. The analysis window can be shown from
> anywhere.
> > Its entry point is declared in a .h-File, so it can be called from
> anywhere
> > (as long as the needed parameters are provided), without having to know
> > anything about the tap system.
> > - There can be multiple analysis windows open (meaning that each one
keeps
> > track of its personal data)
> > - There is a new feature which i called the RTP Streams list, and a
dialog
> > associated with it, which shows all different RTP streams (identified by
a
> > SSRC) present in the capture.
> >  This is nice for a quick overview of all RTP traffic.
> >
> > This is how it works:
> >
> > First a brief recapitulation on how the old tap_rtp worked:
> > It would take the src-ip,-port, dest-ip,-port and SSRC from the selected
> > packet. (If selected packet was not RTP it would return with an error
> > message).
> > With this data, it would do a first redissection to find the SSRC of the
> > reversed direction.
> > If more than one stream with reversed parameters would be found, the
user
> > would have to choose from a list box.
> > Then the second (main) redissection would be carried out, to analyse
> delay,
> > jitter and sequence numbers of forward and reverse streams.
> >
> > Here is how the new module works:
> > There is one tap listener that is connected constantly and keeps
> up-to-date
> > a global list with ALL RTP streams present in the capture.
> > This list can be viewed with an associated dialog box via
> > "Tools/Statistics/RTP Streams.../Show all".
> > The analysis function has been moved to "Tools/Statistics/RTP
> > Streams.../Analyse".
> > There is no more need for the first dissection, since the data can be
> > retrieved from the global RTP streams list.
> > Again, if more than one stream with reversed parameters are be found,
the
> > user will have to choose.
> > But now, he can do so directly in the RTP streams dialog box, which will
> be
> > displayed in that case, with the selected forward stream at the head of
> the
> > list and all possible reverse streams following.
> > The dialog box allows to make two selections: one for the forward and
> > reversed direction.
> > The user needs to choose the streams and press "analyse".
> >
> > The user may also decide to start directly with the RTP streams dialog,
> and
> > use the "analysis" button on any pair of two selected streams.
> > (This is also the default, if no packet is selected when activating
> > "Tools/Statistics/RTP Streams.../Analyse")
> >
> > The new module comes in form of 6 files (3x.cpp, 3x.h) instead of one as
> the
> > old one. :-/
> > But this is to reflect the modularity:
> > - rtp_analysis is the direct successsor of tap_rtp and represents the
> > analysis tap and dialog box.
> >  (GUI and logic still in one file, but much better seperated within)
> > - rtp_stream is the logic part of the stream list and -tap (it does not
> > depend on GUI stuff and could be used in tethereal as well, if useful).
> > - rtp_stream_dlg is the GUI-part of the stream list.
> > ALL 3 .c-files can/have to be declared as ETHEREAL_TAP_SRCs in the
> > /gtk-makefile (for make-ethereal-tap) !!!
> > If rtp_stream.c is delcared, the stream list tap will be registered on
> > start-up.
> > Otherwise it will be registered on demand. (Perhaps better this way,
since
> > not everyone needs the tap running on his dissections!)
> >
> > (Just replace tap_rtp.c with these 3 files anywhere you encounter it in
> the
> > makefiles - this should do)
> >
> > A final note:
> > The development was made with some very specific user request in mind,
for
> a
> > proprietary extension we use here at our office.
> > So i provide this "as is" to whoever might it find useful.
> > Decide yourself if it will be useful for a check-in for a future version
> of
> > Ethereal.
> > Comments will be appreciated.
> > Thanks go to Miha Jemec for its original code, which i took over to
about
> > 75% in rtp_analysis.
> >
> > Tested on Win32/MSVC6 only!
> >
> > I will continue development on this, with the following planned
features:
> > - Additional analysis on tagging errors, payload changes, blanks in the
> > conversation, ...
> > - A conversation diagramm showing packet distribution over time and
> > occurence of errors.
> >
> > Lars Ruoff
> >
>
>
> --------------------------------------------------------------------------
--
> ----
>
>
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
>

Attachment: Makefile.nmake.diff
Description: Binary data