http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2000
jyoung@xxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jyoung@xxxxxxx
------- Comment #6 from jyoung@xxxxxxx 2007-11-25 04:00 GMT -------
I think the fix to the "problem" can be made in ./gtk/rtp_analysis.c.
The procedure rtp_packet_save_payload() includes the following chunk of code:
<snip>
/* if the captured length and packet length aren't equal, we quit
* because there is some information missing */
if (pinfo->fd->pkt_len != pinfo->fd->cap_len) {
saveinfo->saved = FALSE;
saveinfo->error_type = TAP_RTP_WRONG_LENGTH;
return 0;
}
<snip>
The "Save Payload" function of the "RTP Stream Analysis" sees that the frame is
truncated and assumes that there is NOT enough data to extract the RTP payload.
But that's not actually the case, the entire 160 byte RTP payload is present.
In the version 3.4 trace file there's actually four extraneous bytes of data
AFTER the 160 byte RTP payload.
In the version 3.6 trace file (the one with the "truncated" frames) these four
extraneous bytes are missing, BUT the entire 160 byte RTP payload IS present.
It appears that with v3.6 of the CISCO Network Analysis Modules (NAM) they
choose to truncate (snaplen) the frames at 218 bytes because they knew they
would have captured the entire 160 RTP payload.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.