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
"attached is a simple fix for CID281213. Although the bug can't crash wireshark,
dissect_si_string() is not really fit for handling negative string lengths (and
doesn't need to)."
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7243
svn path=/trunk/; revision=42523
For each message, the DVB-CI dissector checks the message size against the
buffer size negotiated at startup. If the buffer size negotation was not
captured, a warning is flagged up for each packet saying its size is too big.
Obviously, the check only makes sense if we know the negotiated buffer size...
svn path=/trunk/; revision=41901
The attached patch for the DVB-CI dissector creates a circuit for each DVB-CI
session, using the session number as circuit id.
The DVB-CI session commands are:
- open_session_request(resource_id)
- session_opened(resource_id, newly assigned session number)
- payload transfer(session_number, payload data)
- close session(session_number)
For now, the circuit will store the resource id and make it available (as a
generated item) to subsequent packets that contain only the session number.
Doing this, the resource id (which is like a tcp/udp port) can be used for
filtering.
svn path=/trunk/; revision=41253
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
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
Implement the content control resource from the CI+
specification 1.2.
From me:
Change ENC_NA to ENC_BIG_ENDIAN as i suppose this is a big endian protocol and ENC_NA was erroneously used for irems bigger than i byte in some cases.
svn path=/trunk/; revision=39143
Martin Kaiser