Re: [Wireshark-users] Is there a tshark option to save just RTP Header?
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. ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
Re: [Wireshark-users] Is there a tshark option to save just RTP Header?
On May 31, 2007, at 5:13 PM, Stephen Fisher wrote: > On Thu, May 03, 2007 at 05:29:24PM -0400, Kerry L Foster wrote: > >> Is it possible to control what information is being saved by tshark >> into the output capture file? > > The only way that I know of is the -s option, which > specifies how many bytes of each packet to read/save. This could be > used in your case as long as all of the packets had the exact same > length for the lower level protocols (ethernet, ip, udp, etc.) Unfortunately, that can be used to *throw away* the RTP header, but can't be used to save *only* the RTP header - a snapshot length of N means "save only the first N bytes of the packet". ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
Re: [Wireshark-users] Is there a tshark option to save just RTP Header?
On Thu, May 03, 2007 at 05:29:24PM -0400, Kerry L Foster wrote: > Is it possible to control what information is being saved by tshark > into the output capture file? The only way that I know of is the -s option, which specifies how many bytes of each packet to read/save. This could be used in your case as long as all of the packets had the exact same length for the lower level protocols (ethernet, ip, udp, etc.) > 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 based upon the > preference setting (it could simply zero out RTP payload, or maybe > even modify the UDP/RTP lengths, etc.). It looks like dissect_packet() > passes a pointer to the original packet data and not to a copied > buffer, so it looks feasible. That is probably the best place to put this sort of feature. Steve ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
[Wireshark-users] Is there a tshark option to save just RTP Header?
Hi to all. 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? 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). 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 based upon the preference setting (it could simply zero out RTP payload, or maybe even modify the UDP/RTP lengths, etc.). It looks like dissect_packet() passes a pointer to the original packet data and not to a copied buffer, so it looks feasible. We (as a telecom vendor) really have a need for this kind of capability since several telecom operators are becoming reluctant to send us their entire SIP/RTP packets due to increasing privacy concerns. And we really don't need the RTP payload captured unless we're diagnosing Voice Quality/Encoding problems. In most cases, RTP Header is enough for debugging most Signaling problems. Any comments, concerns? Thanks in advance, Kerry Foster ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
