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
tipc: update link header according to spec
The bcastsequence gap have been removed, and the sequence field is now 13 bits.
svn path=/trunk/; revision=48238
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
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
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_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
(1) Trailing/leading spaces are removed from 'name's/'blurb's
(2) Duplicate 'blurb's are replaced with NULL
(3) Empty ("") 'blurb's are replaced with NULL
(4) BASE_NONE, NULL, 0x0 are used for 'display', 'strings' and 'bitmask' fields
for FT_NONE, FT_BYTES, FT_IPv4, FT_IPv6, FT_ABSOLUTE_TIME, FT_RELATIVE_TIME,
FT_PROTOCOL, FT_STRING and FT_STRINGZ field types
(5) Only allow non-zero value for 'display' if 'bitmask' is non-zero
svn path=/trunk/; revision=28770
Enhancement:
- TIPC is available in a new version (1.7), adding/removing fields while
keeping the same version number (2).
Minor bugs:
- In NAME_DISTRIBUTOR messages the origianting and destination node are
switched.
- The used size of BUNDLER messages payload is not calculated correctly when
size%4=0, this leads to the wrong assumption that the message would be
malformed.
svn path=/trunk/; revision=23291
- reassembling of fragmented TIPCv2 messages
- calling of heuristic subdissectors
- multicast upper+lower bound header fields are now shown
- corrects few typos in the comments in packet-tipc.c
svn path=/trunk/; revision=22889
Changes are only for protocol version 2.
The changes are:
- dissect "TIPC Bundler Protocol" messages correctly
- search for other dissectors which want to dissect encapsulated data according to the TIPC user or TIPC type of a message. The data dissection is difficult since a TIPC data message does not necessarily a "type" set. So for the moment - while TIPC is not widely used - just triggering for the user of a message will be sufficient for people looking into the TIPC protocol.
- "Dissect TIPC data" in the preferences is now switched on by default
- to show undissected data, the "data" dissector is now used.
- corrected some typos
svn path=/trunk/; revision=22183