Change-Id: Id1997c3c8f6d0460da7f0faa58798a72737dd667
Reviewed-on: https://code.wireshark.org/review/2898
Reviewed-by: Michael Mann <mmann78@netscape.net>
Change-Id: Ia2567695ffed30c990eda3740b08bfab101cea96
Reviewed-on: https://code.wireshark.org/review/2883
Reviewed-by: Michael Mann <mmann78@netscape.net>
Also, note that we need to determine how to handle Application Layer
Feedback messages based on the SDP setup traffic for the session; recent
changes disabled dissection of REMB Application Layer Feedback messages
in favor of MS-RTP Application Layer Feedback messages. (This is why we
shouldn't remove dissect_rtcp_psfb_remb() unless REMB isn't being used
any more.)
Change-Id: Ib320bdf4a64263fdef29fc4ea2583eaae1cc4bee
Reviewed-on: https://code.wireshark.org/review/2684
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Support for Profile Specific Extensions from MS-RTP
Support for RTCP Feedback Messages
Support for Application Layer Feedback Messages.
MS-RTP: Real-time Transport Protocol (RTP) Extensions
http://msdn.microsoft.com/en-us/library/office/cc431492.aspx
Change-Id: I1f1e6e60b5f9d09b1dffd7e308426c0b67914441
Reviewed-on: https://code.wireshark.org/review/2586
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Hopefully that name makes it clear what the routiner's purpose is, and
will encourage people to use it rather than using dissector_add_uint()
with a bogus integer value.
Change-Id: Ic5be456d0ad40b176aab01712ab7b13aed5de2a8
Reviewed-on: https://code.wireshark.org/review/2483
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Most (all?) of these functions are being called within GUI, so they can't have packet_scope, which is why they weren't already converted (I made this mistake once already)
This reverts commit 7fea55a054.
Change-Id: I4bf29b206e5e1f5daefcec131309a8f6e78e1eb1
Reviewed-on: https://code.wireshark.org/review/2428
Reviewed-by: Michael Mann <mmann78@netscape.net>
tvb_new_subset -> tvb_new_subset_remaining it appears that's what the intention is.
Change-Id: I2334bbf3f10475b3c22391392fc8b6864454de2d
Reviewed-on: https://code.wireshark.org/review/1999
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
wmem_packet_scope() cannot be used outside of a packet treatment
Change-Id: I6e545bbb51f325b366288f17358f9d2347a7d7c4
Reviewed-on: https://code.wireshark.org/review/977
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Change-Id: I7489e2fb3a1f2630ca17b0a5fe1aa873992f1061
Reviewed-on: https://code.wireshark.org/review/975
Reviewed-by: Michael Mann <mmann78@netscape.net>
(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
I'm not sold on the name or module the proto_data functions live in, but I believe the function arguments are solid and gives us the most flexibility for the future. And search/replace of a function name is easy enough to do.
The big driving force for getting this in sooner rather than later is the saved memory on ethernet packets (and IP packets soon), that used to have file_scope() proto data when all it needed was packet_scope() data (technically packet_info->pool scoped), strictly for Decode As.
All dissectors that use p_add_proto_data() only for Decode As functionality have been converted to using packet_scope(). All other dissectors were converted to using file_scope() which was the original scope for "proto" data.
svn path=/trunk/; revision=53520
1. Case sensitivity differences between hf_ field name and formatted string.
2. Unnecessary whitespace between hf_ field name and colon in formatted string
There are cases where the hf_ field name doesn't quite match the proto_tree_add_uint_format, but it's close enough that one of them should be "right", I'm just not sure which is, I just know the string in proto_tree_add_uint_format is the one displayed.
svn path=/trunk/; revision=52098
The script didn't catch as many as I would have liked, but it's a start.
The most common (ab)use of proto_tree_add_uint_format was for appending strings to CRC/checksum values to note good or bad CRC/checksum.
svn path=/trunk/; revision=52045
Cast away some implicit 64-bit-to-32-bit conversion errors due to use of
sizeof.
Cast away some implicit 64-bit-to-32-bit conversion errors due to use of
strtol() and strtoul().
Change some data types to avoid those implicit conversion warnings.
When assigning a constant to a float, make sure the constant isn't a
double, by appending "f" to the constant.
Constify a bunch of variables, parameters, and return values to
eliminate warnings due to strings being given const qualifiers. Cast
away those warnings in some cases where an API we don't control forces
us to do so.
Enable a bunch of additional warnings by default. Note why at least
some of the other warnings aren't enabled.
randpkt.c and text2pcap.c are used to build programs, so they don't need
to be in EXTRA_DIST.
If the user specifies --enable-warnings-as-errors, add -Werror *even if
the user specified --enable-extra-gcc-flags; assume they know what
they're doing and are willing to have the compile fail due to the extra
GCC warnings being treated as errors.
svn path=/trunk/; revision=46748
Feedback NACK PID", not just as "RTCP Transport Feedback NACK", and give
the field a name for that.
Use it in the protocol tree for the bits of the BLP field, rather than
making it a hidden field there.
Clean up the tags appended to the BLP field.
svn path=/trunk/; revision=45157
text.
Don't put empty items into the bitfield tree.
Show the BLP field as hex, as it's a bitfield.
(What should *really* happen is that it should display each 1 bit in the
usual fashion, with the ".... ...1 .... ...." display, but have that bit
be an *integral* field with the appropriate PID for the NACKed packet -
i.e., display hf_rtcp_rtpfb_nack_pid, with the value
rtcp_rtpfb_nack_pid + i + 1, and with the bitfield stuff in the
displayed representation.)
svn path=/trunk/; revision=45155
Alexis La Goutte