Wireshark · Ethereal-dev: Re: [Ethereal-dev] tapping commentary

[Jason House <jhouse@xxxxxxxxx>]

Pia Sahlberg wrote:

> Hi Jason
>
> Yes, definitely, it would be a BUG if the tap system did call the tap again
> just because the user clicked on a packet in the list.
> However, since the tap is inside add_packet_to_packet_list() in file.c and
> AFAIK this function is only called whenever ethereal reads a packet from an
> interface or a file.
> AFAIK this funciton will NOT be called when the user selects a packet and
> thus the tap system will not be called.

Well that is definitely good for most taps.  Now consider the case for if there
was another (separate) place for where a tap *could* be called in response to a
user clicking on a packet.  The previously mentioned "forgetful" tap could
benefit from being called from *only* from this new location and thus provide a
graphical packet comparison mechanism.  Likewise having it *only* called from
the original tap point (add packet to packet list) could also have a benefit in
that it could show the current near-realtime changes of the network topology.
Creating tap calls in either case can be useful, while in both is (most likely)
not.  It would be an interesting feature if a tap listener could be configured
to run off either tapping location.  I don't know how color filters (and
similar) will be implemented as taps, but they potentially might benefit from a
distinct location in the code where a tap listener can be called from.
Previously, I referred to each potential location in the code to call a tap
listener as a "tap event"... simply meaning that you've reached a point in the
code where you may want to call tap listeners, but that only certain taps should
be called from that point...  Hopefully, eventually, I'll explain this clearly.


> >  I have a particular graphic application in mind where the latest
> >network topology is graphed in a window on the screen (and optionally
> >highlighting changes from the previous pictured topology)...  Having one
> >window
> >of "the current network status" and another window for "the current
> >packet(s)
> >that the user is currently viewing/comparing".  In that specific scenario,
> >separating the first (automated) dissection/tapping and the subsequent
> >(user-induced) tapping becomes highly important.
>
> That sounds really nice.
> I would be interested in seeing if someone  can actually use tap to produce
> an extension and when doing so also
> add the missing documentation , what is unclear, so it gets even easier for
> the next one.
>
> Perhaps you could implement a dead simple tap extension for
> tethereal/gtk/gtk2 as the first warming up
> excersise?   I am thinking of something like a FrameSizeHistogram which
> would be small and simple.
> It could tie in to -z io,    as the patch I sent in a few days ago do. That
> one is not in CVS since I am internet disadvantaged for a week or two more
> and cant do it myself.   Hopefully some of the other developers will check
> it in.
>
> Perhaps something like   -z
> io,fsh,frame,<max-size>,<num-intervals>[,<filter>]    that attaches to
> "frame" tap.
>
> I would be very interested in your experiences when developing a tap
> extension so that I can update the documentation for it.

I do have code that modified a packet-XXX file for displaying a single packet.
I'm fairly certain that I can't share the code, but I would be interested in
trying to do some kind of demo... I should try and think of a good way to
actually do one...  My initial thoughts are quite simple... have a tap listener
that returns true every time, and have ethereal check if an update is required
after tapping a packet, and if so, call the draw routine... and let draw use the
private data to possibly hold widget data for displaying to the screen.  As I
write this I think of many more items and nuances to write, but I know that they
are just thoughts on extension that I would not put in any initial "demo"...  I
am very interested in doing the demo, but alas should not spend a long time on
it...   Not sharing what I already have makes it a bit more complicated, but
I'll think about it and try to see what I can do (relatively) quickly...


> >     I believe that the private listener data (rs for rpcstat), is passed
> >on
> >every call to the tap, and so a simple mechanism of rs->packet_num will not
> >work, as it will simply tap a specific # of packets and then stop as
> >opposed to
> >separating different collections of tap events...
>
> But,  *rs  is a dynamically allocated structure describing all data for a
> specific tap instance.
> Even if you start 2 or three separate rpcstat tap listeners, they will all
> have their own unique *rs structure
> independently of each others.
> The *rs struct is a tap listener specific structure, the tap system does not
> know what it is, it just thinks it is a void*.
> *rs is not known nor used outside of tap_rpcstat.c
>
> Please be clearer in describing what you mean above.
> Do you mean that you want something like    After packet X is received from
> tap FOO, start tapping 200 packets on tap BAR?
> That is simple as well.
> Start by setting up a tap FOO to trigger the event "Packet X".
> When the FOO tap triggers on event "Packet X", let FOO_packet() callback do
> a register_tap_listener() for BAR.
> Then for all further packets in the capture, BAR is used.

Hmm... I have to be very careful with wording.... No that is not what I meant.
Hopefully the first part of my e-mail will help clarify exactly what I meant.  I
was simply trying to say that a packet counter would not help to do what I was
thinking of.  My commentary about the listener's private data was that there is
one copy per tap instance, and not one copy per packet per tap instance (or some
other similar variant).


> >   I think that the tap event types may have
> >more utility than the tap-writer initially envisions.
>
> The tap-writer, that would be me. :-)

I meant tap listener-writer


> >If the tap core handles
> >all filtering, then it empowers the user and keeps the taps from having to
> >change with each new extension of tap filtering...
>
> The tap core DOES filtering!   But it only does filtering on normal display
> filters.

I know it does filtering already and I was (apparently unsuccessfully) trying to
tie that fact into the point I was trying to make about taps getting called from
certain "tap events"...  The choice of where in the code (one or more) to call a
tap listener from could be viewed as another filter-like mechanism... selective
calling of a tap listener for certain packets at certain places in the code.