Ethereal-dev: Re: [Ethereal-dev] Some thoughts...
> 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.)
> 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.
> 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.
> 4. The concept of dissector summary statistics seems to be missing.
That's because it *is* missing.
> 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).
"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).
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.
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.
