as a voip_call_state value; don't have it sometimes a voip_call_state
and sometimes a frame subtype.
This should squelch some complaints from newer versions of Clang about
unnecessary array-bounds checks - the array-bounds checks are done on
frame subtypes, where they *are* necessary (nothing prevents an
untrustworthy IAX2 implementation or an untrustworthy capture file
writer from putting an arbitrary value in the packets), not on
voip_call_state values (where it was only necessary because the value
wasn't, in that case, a voip_call_state value, it was a frame subtype
cast to a voip_call_state).
svn path=/trunk/; revision=50277
be done on flows from one address to another; reassembly for protocols
running atop TCP should be done on flows from one TCP endpoint to
another.
We do this by:
adding "reassembly table" as a data structure;
associating hash tables for both in-progress reassemblies and
completed reassemblies with that data structure (currently, not
all reassemblies use the latter; they might keep completed
reassemblies in the first table);
having functions to create and destroy keys in that table;
offering standard routines for doing address-based and
address-and-port-based flow processing, so that dissectors not
needing their own specialized flow processing can just use them.
This fixes some mis-reassemblies of NIS YPSERV YPALL responses (where
the second YPALL response is processed as if it were a continuation of
a previous response between different endpoints, even though said
response is already reassembled), and also allows the DCE RPC-specific
stuff to be moved out of epan/reassembly.c into the DCE RPC dissector.
svn path=/trunk/; revision=48491
are like the non-TVB versions except that they take a TVB and an offset
instead of (frequently) a pointer into the TVB.
Calling tvb_get_ptr() before modifying the rest of the fields should help fix
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7960 (though I can't
reproduce that problem).
Replace a bunch of calls like:
SET_ADDRESS(..., AT_XXX, length, tvb_get_ptr(tvb, offset, length));
with:
TVB_SET_ADDRESS(..., AT_XXX, tvb, offset, length);
svn path=/trunk/; revision=46324
Also:
- Create/use several extended value strings;
- Reformat hf[] array;
- Do various whitespace and formatting changes to use a consistent style.
svn path=/trunk/; revision=46210
The reassembled fragments tree in the Packet Details view is awesome, but it
lacks one thing: a field that exposes the reassembled data.
tcp.data already exists for exposing a single TCP segment's payload as a byte
array. It would be handy to have something similar for a single application
layer PDU when TCP segment reassembly is involved. I propose
tcp.reassembled.data, named and placed after the already existing field
tcp.reassembled.length.
My primary use case for this feature is outputting tcp.reassembled.data with
tshark for further processing with a script.
The attached patch implements this very feature. Because the reassembled
fragment tree code is general purpose, i.e. not specific to just TCP, any
dissector that relies upon it can add a similar field very cheaply. In that
vein I've also implemented ip.reassembled.data and ipv6.reassembled.data, which
expose reassembled fragment data as a single byte stream for IPv4 and IPv6,
respectively. All other protocols that use the reassembly code have been left
alone, other than inserting NULL into their initializer lists for the newly
introduced struct field reassemble.h:fragment_items.hf_reassembled_data.
svn path=/trunk/; revision=44802
Essentially: 'fid' & 'fragment' hash tables can be global (i.e., need not be 'per call')
thus removing g_malloc'd storage never freed because it was pointed to in
se_alloc'd structs.
Fixes Bug #4134: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4134
Also: fix a compile error when compiling with '#define DEBUG_DESEGMENT'
svn path=/trunk/; revision=44685
Also (for a few files):
- create/use some extended value strings;
- remove unneeded #include files;
- remove unneeded variable initialization;
- re-order fcns slightly so prefs_reg_handoff...() at end, etc
svn path=/trunk/; revision=44438
proto_tree_move_item(): that function will expects the item, not its parent.
This avoids dissector bugs such as the one reported in
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6768 :
** (process:745): WARNING **: Dissector bug, protocol RTP, in packet 82:
proto.c:4273: failed assertion "fixed_item->parent == tree"
svn path=/trunk/; revision=41021
Don't use tvb_get_ptr() to retrieve a string being sent into
proto_tree_add_string_format(): use tvb_get_ephemeral_string() instead.
svn path=/trunk/; revision=40944
Some commands and IEs from the current release of Asterisk are missing from the
IAX protocol dissector. This patch provides them.
svn path=/trunk/; revision=40141
1. If there's no character encoding (ENC_ASCII, ...) specified
then use ENC_ASCII.
2. For all but FT_UINT_STRING, always use ENC_NA
(replacing any existing True/1/FALSE/0
/ENC_BIG_ENDIAN/ENC_LITTLE_ENDIAN).
svn path=/trunk/; revision=39426
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_BOOLEAN
FT_IPv4
FT_EUI64
FT_GUID
FT_UINT_STRING
Also: For type FT_ITv6 use ENC_NA. (This was missed in SVN #39260)
svn path=/trunk/; revision=39328
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_UINT8
FT_UINT16
FT_UINT24
FT_UINT32
FT_UINT64
FT_INT8
FT_INT16
FT_INT24
FT_INT32
FT_INT64
FT_FLOAT
FT_DOUBLE
svn path=/trunk/; revision=39288
FT_NONE
FT_BYTES
FT_IPV6
FT_IPXNET
FT_OID
Note: Encoding field set to ENC_NA only if the field was previously TRUE|FALSE|ENC_LITTLE_ENDIAN|ENC_BIG_ENDIAN
svn path=/trunk/; revision=39260
keys to have _uint in their names, to match the routines that handle
dissector tables with string keys. (Using _port can confuse people into
thinking they're intended solely for use with TCP/UDP/etc. ports when,
in fact, they work better for things such as Ethernet types, where the
binding of particular values to particular protocols are a lot
stronger.)
svn path=/trunk/; revision=35224
See: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4868
A field length was being set incorrectly (too large) thus causing
packet_hex_apply_reverse_tag() to run off the end of a text_view buffer
(thus causing a crash) when attempting to highlight the field bytes
in the hex-view pane.
ToDo: Add some sanity checking in packet_hex_apply_reverse_tag().
svn path=/trunk/; revision=33212
Jakub Zawadzki