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
I've written this patch to use the 'Delay since last SR' (DLSR) field found
in SR reports to calculate and report roundtrip-propagation delays. This is
described in rfc 3550, section 6.4.1, inside the description of DLSR.
Only the endpoint can compute the end-end roundtrip delay, and only they
know exactly when the report is received and can compare it with the 'Last
SR timestamp' (LSR) that they set. This patch instead takes the difference
between the capture times of the 2 reports and subtracts the DLSR (the LSR
is checked in case the SR it's referring to wasn't captured). The time
difference represents a roundtrip network delay between the point of capture
and the sender of the SR containing the DLSR.
svn path=/trunk/; revision=11998
- test for NULL conversation data to avoid a potential crash when
looking up stream setup info (as RTP dissector does);
- adds a heuristic function (like RTP, this is a preference
initially set to off).
svn path=/trunk/; revision=11748
Also move ncp222.py, x11-fields, process-x11-fields.pl,
make-reg-dotc, and make-reg-dotc.py.
Adjust #include lines in files that include packet-*.h
files.
svn path=/trunk/; revision=11410