[PC Drew <drewpc@xxxxxxxxxxxx>]

--On Thursday, April 26, 2001 11:09 AM -0700 Guy Harris <guy@xxxxxxxxxx> 
wrote:

> > I've got a bunch of ideas that I wanted to run by you guys before I
> > started  to implement them:
> >
> > 1.  It'd be nice if the port numbers were on the summary line of the RTP
> > header...does anyone mind if I add this?
>
> Well, I'm not one of the streaming guys in the NetCache group here at
> NetApp, so it wouldn't make a difference to me; however, note that you
> can include columns in the summary for the source and destination port
> number of the packet - see the "Columns" tab in the "Edit->Preferences"
> dialog box.  (Note that the new columns currently don't show up until
> you exit Ethereal and restart, after saving the preferences with the
> "Save" button; that will probably be fixed at some point.)

Ah-hah!  I did not realize this!  Is there any way to do this in tethereal 
too?  Probably not.

> > 3.  Right now (as I understand it), with tethereal you have "on" and
> > "off"  as to the verbosity level (either summary line or the whole
> > tree).  I'd  like to make 2 changes if everyone's okay.  I'd like the
> > ability to  specifiy "decode from this protocol down" in the tree.
> > Meaning, if I'm  looking at a SIP message, I only want to see the SIP
> > stuff (and anythinb  below it in the tree), but I don't want to see the
> > tcp/udp, ip, or  etherenet decodes.
>
> That'd probably be reasonable - the command-line option would control
> which tree levels were expanded, and, if the command-line option were
> specified, Tethereal would set "print_args.expand_all" to FALSE rather
> than TRUE, so the printing code would only expand the tree items in
> question.

exactly.  Okay, I'll get started on this.

> > Secondly, it'd be nice if you could print out certain
> > variables in addition to the summary line.  If I can filter based on the
> > variable, why not allow people to print it out?  This way, I could print
> > only the summary line, but I could also see certain variables (i.e.
> > udp.srcport, sip.msg_hdr, etc).
>
> Well, "udp.srcport" could, as indicated above, be shown if you select
> "Src port" as one of the columns.

Sorry, I guess I wasn't very clear.  I meant in tethereal.  In ethereal, 
you already have access to those variables by looking in the tree (or 
adding it to the column as you recommended).

> > 4.  The concept of dissector summary statistics seems to be missing.
>
> That's because it *is* missing.

I tell ya, I'm a master of the obvious :)

> > For
> > instance, I want to be able to display statistics related to the RTP
> > conversations that have been captured (i.e. jitter, packet loss,
> > latency,  etc).  I've been working on implementing this and I'll send my
> > work to the  group when I've got a working copy.  Basically, it's setup
> > just like the  protocol registration...you call "register_summary" in
> > the proto_register_*  routine, giving it certain parameters that tell
> > the system which functions  to call to get the summary information for
> > that protocol.  Then, it's up to  the dissector to update the summary
> > information for itself, and finally,  when the user wants to view the
> > summary information for that protocol, the  system calls a
> > "get_summary"-ish function and hands the function a  GtkWidget  that's
> > inside a newly created window for the dissector to  display its stuff
> > (i.e. numbers, graphs, images, etc).  Don't worry, I've  also accounted
> > for tethereal :)
>
> How have you accounted for Tethereal?
>
> Note that "with ifdefs in the dissectors" is almost certainly the wrong
> answer; the same plugin dissector loadable modules must work with
> Ethereal and Tethereal, and the same non-plugin dissector object modules
> have to link into both Ethereal and Tethereal (unless you do some fairly
> major Makefile surgery, assuming that's even possible).

I agree.

> "Tethereal now links with GTK+" is definitely the wrong answer, as there
> are people who want to be able to build Tethereal on machines that don't
> have X11 installed (which is why you *can* build only Tethereal - those
> people asked for it).

I agree.

> Note also that there is no guarantee that even all future interactive
> versions of Ethereal will use GTK+ - we may do curses-based, or
> Qt/KDE-based, or Windows MFC-based, or...  versions in the future, in
> addition to the current GTK+ one - so even for interactive versions, the
> dissectors should not do any GTK+ stuff, only GLib stuff.

I agree with that too.

> What would, I suspect, work better would be if the "get_summary"-ish
> routine supplied a list of names and values, with the summary dialog box
> showing
>
> 	 Name: value
>
> for each of them.

That is a good solution...except if you want to get into graphing stuff. 
I'm not there yet, but here's my proposed solution:

There's a register_summary function where you pass it the proto_id, the 
short name, a pointer to a gtk function that takes a conversation_t 
argument and a gpointer argument that points to a GTKWidget container (i.e. 
the summary window would already be created and the function would get 
passed the container GTKWidget in gpointer form.

The dissector is responsible for adding everything into a glist (or some 
container, I haven't decided yet) and calling a generic summary function 
called "done_creating_summary" or something.  That in turn calls a GTK 
function that adds it to the window with the appropriate container.

For tethereal, it will call the terminal summary function (i.e. 
rtp_term_summary), which does the same thing as the GTK summary function, 
only it prints it to the terminal.

--
PC Drew

 Be nice or I'll replace you with a very
 small shell script.