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

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

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: "Pia Sahlberg" <piabar@xxxxxxxxxxx>
Date: Wed, 16 Oct 2002 23:18:52 +0000
Hi Jason


    I think I phrased #2 (below) poorly.  Let me try again...
    When you perform an "update capture in real time", the main thread
periodically reads the updated temporary capture file and dissects/taps each packet that it encounters. The user meanwhile can go back and click on a packet 
that was already previously dissected/tapped and it will then be
dissected/tapped again. This revisiting of a packet can potentially wreak havoc 
on a tap.


Ok. I see what you mean.
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. 




 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 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.
Does this make sense? If the functionality is placed inside the tap, then 
it must somehow recognize which type of event has caused the tap call
(potentially via info in pinfo that is already passed in) and act if
appropriate. The problem I see with doing that approach is that the tap must be smart enough to separate tap event types. To me, it seems that things like the display filter (for tapping) and filtering by tap event type fall into the same 
category of "handled elsewhere"...
display filter and color filter matching are definitely something that would fit well inside the tap semantics. 
I belive it should be looked into and am doing so.


  I think that the tap event types may have
more utility than the tap-writer initially envisions.


The tap-writer, that would be me. :-)



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. See what happens if you do ./tethereal -n -r foo.cap -z rpc,rtt,100003,3,nfs.fh.name==foo -z rpc,rtt,100003,3,nfs.fh.name==bar
It adds two separate tap listeners, each with its own independent *rs structure. The first one registers to the tap core with a "display" filter "nfs.fh.name==foo" meaning that the tap core 
will only call the _packet() callback IFF the packet matches the filter.
Same for the second instance.


best regards
    ronnie sahlberg



_________________________________________________________________
Broadband? Dial-up? Get reliable MSN Internet Access. http://resourcecenter.msn.com/access/plans/default.asp