cannot be stored in guint32).
- Makes the threshold preference value an absolute value.
- There is now a separate expert info item for -ve roundtrips
N.B. There is still a problem with filtering -ve values on this
FT_INT32 field, i.e. rtcp.roundtrip-delay < 0 never matches with
frames that it should (even if rtcp.roundtrip-delay == -3 can
be used to match specific frames...).
svn path=/trunk/; revision=20264
- updated to the current (approved) spec. I'm not sure how backwards-compatible this is with older drafts...
- prettified the existing code, including more details in the info column
Also included is a fix to the way the offset at the end of an RTCP BYE packet is calculated (taking into account the NULL. This avoids the 'length wrong' expert item)
svn path=/trunk/; revision=18820
- shows profile-specific extension data at the end of SR/RR reports (if
packet length has not yet been reached after parsing normal data) and
advances offset (further packets were not recognised+dissected as this
data wasn't being skipped).
- checks that the length of the RTCP data in the whole frame matches the
combined length from the length fields (the last check in RFC 3550, "A.2
RTCP Header Validity Checks") with a generated field and expert info
when wrong.
- reports the length field in all of the message types consistently (the
length was confusingly shown multiplied by 4 only in APP packets...)
svn path=/trunk/; revision=18357
- shows profile-specific extension data at the end of SR/RR reports (if
packet length has not yet been reached after parsing normal data) and
advances offset (further packets were not recognised+dissected as this
data wasn't being skipped).
svn path=/trunk/; revision=18245
While looking at bug 882 (which seems to have been fixed since 0.10.14) I noticed the RTCP heuristic dissector wasn't picking up the frame.
This patch fixes the parenthesis to test the packet-type properly.
svn path=/trunk/; revision=17914
- fixes bug 863 (RTCP sender report's NTP time display incorrect - use using wrong bytes)
- makes NTP timestamp MSW and LSW proper filterable fields, displaying them in dec and hex
- when doing roundtrip calculations, rationalise fields added, add link to LSR frame whenever it matches
svn path=/trunk/; revision=17834
I keep finding finding traces that show new problems with this code. This patch fixes 2 problems:
- I've seen RTCP frames containing a SR and RR with identical source info and the lsr matching the current MSW/LSW timestamp of the SR. Don't want to do calculation without real roundtrip info
- calculating the gap between the 2 frames was still wrong (sigh)
svn path=/trunk/; revision=16934
"tvb_get_string()"?
Why even bother with "tvb_get_string()" when you can just use
"proto_tree_add_item()" with a string item?
Make sure that the prefix in a PRIV item isn't bigger than the item
itself. That fixes bug 603.
svn path=/trunk/; revision=16716
Hi, Some tiddly changes: pppoe- don't create an empty discovery tags tree when the payload length is 0 chap- make chap.value work as a filterable field rtcp- append the packet type to the protocol tree name
svn path=/trunk/; revision=16712
ptr.
The answer to the question
"??????????????????????????????????????????????????????????????????" is
"No - the return value of tvb_get_ptr() is a reference, not an allocated
copy, and it cannot be freed and doesn't need to be freed."
svn path=/trunk/; revision=16426
at the same time change ntp_fmt_ts to return a pointer to ian ep-allocated buffer.
remove the redundant buffer parameter in the signature and change all callers.
svn path=/trunk/; revision=15939
I've done more than a day to change the timestamp resolution from microseconds to nanoseconds. As I really don't want to loose those changes, I'm going to check in the changes I've done so far. Hopefully someone else will give me a helping hand with the things left ...
What's done: I've changed the timestamp resolution from usec to nsec in almost any place in the sources. I've changed parts of the implementation in nstime.s/.h and a lot of places elsewhere.
As I don't understand the editcap source (well, I'm maybe just too tired right now), hopefully someone else might be able to fix this soon.
Doing all those changes, we get native nanosecond timestamp resolution in Ethereal. After fixing all the remaining issues, I'll take a look how to display this in a convenient way...
As I've also changed the wiretap timestamp resolution from usec to nsec we might want to change the wiretap version number...
svn path=/trunk/; revision=15520
"decode_boolean_bitfield()" returns a "const char *" - don't cast it to
a "gchar *" and modify what it points to. Instead, just use
"other_decode_bitfield_value()".
svn path=/trunk/; revision=13494
1) Added a setup_frame parameter to conversation_t
2) Used the conversation_t next to maintain a list of conversations with the
same src/dest tuple but different setup_frame number.
3) Changed the signature of find_conversation() and conversation_new() to pass
in the frame number.
4) Adjusted packet-sdp to select RTP conversation if both m=audio and m=image
are present, and T.38 conversation if only m=image is present. I expect that
RTP/T.38 dissecting to be better, but I don't have a way to generate T.38
packets.
svn path=/trunk/; revision=13243
that doesn't mean it's padding at the end of a previous item - it might,
for example, be the *first* item in the chunk. Don't treat it as
padding.
Do, however, treat an item that begins with a zero byte as an item, but
break out of the loop processing items as soon as the item type is put
into the protocol tree, as there's no length field or data in an
RTCP_SDES_END item. Fix the comment for that loop to indicate that the
loop checks both for end-of-frame and for an RTCP_SDES_END item.
svn path=/trunk/; revision=13040