[Guy Harris <guy@xxxxxxxxxxxx>]

On May 3, 2007, at 2:29 PM, Kerry L Foster wrote:

> Is it possible to control what information is being saved by tshark  
> into
> the output capture file? For instance, if tshark is using the display
> filter '-R "sip or rtp"' to capture SIP and RTP packets, can I tell
> tshark just to write out the RTP header-only (along with SIP  
> packets) to
> the output file?

No.

> Currently, I assume I would have to run two captures;
> one for SIP packets and a second for RTP with the snaplen option set  
> to
> 54 to truncate those RTP (UDP) packets. And then later merge the two
> captures back together. I would like to be able to do this from one
> capture session (better on CPU usage).

If by "CPU usage" you mean CPU usage during the capture, you would  
probably be best advised not to do any censoring in the capture  
process, and do the censoring as a post-processing operation.

> I assume tshark does not support this capability which leads me to the
> next question. If I (or someone else) were to implement this  
> capability
> (to contribute back), where would the best place be to add it? Could I
> add it as a preference within the RTP dissector (something like '-o
> rtp.clear_payload:TRUE')?   Then from the RTP dissector, just  
> manipulate
> the tvb->real_data buffer or tvb->length

Manipulating tvbuffs, or their contents, in place is not allowed in  
dissectors (dissectors must treat them as read-only, as they have no  
idea what other code might expect the tvbuff to be unchanged).  The  
real_data pointer is a const pointer by design and intent - it's  
*supposed* to keep you from modifying it.

You would be best advised to implement this as a tap.  The tap could  
take a file name as an argument, and use the calls in the Wiretap  
library (in the "wiretap" subdirectory) to write out a new capture  
file.  The "edt" argument to the tap points to an epan_dissect_t  
structure, one of the members of which is a tvbuff_t.  You can *copy*  
the data from that tvbuff, modify it, and write that data out.  The  
pinfo structure can be used to find time stamps, etc..  The "tree"  
member of the epan_dissect_t can be used to find out where the payload  
is in the packet, so you know where to start zeroing out the data in  
the copy.  If no RTP payload is found, just write out the uncensored  
data.

Note, however, that, if an RTP packet is contained in a UDP datagram  
that's inside a *fragmented* IP datagram, the tap will be called with  
an epan_dissect_t structure with a tvbuff that refers to the *last  
fragment* of the datagram.  There is currently no infrastructure  
sufficient to support "censoring" reassembled packets.

Given the limitations of the current infrastructure, you might be best  
advised to implement this as a plugin tap, rather than as something  
that's part of the Wireshark code base.