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
Several updates to the DCE/RPC dissector:
- changed the variable name "ndr64_uuid" to "uuid_ndr64" to make it similar the
the other UUID variable names. Minor changes to the UUID names.
- changes the UUID name for the 32bit NDR to describe that. In the DCE/RPC
standard this UUID is described as "Version 1.1 network data representation
protocol", but this is an unnecessarily long name and it's the only 32bit
version defined for DCE/RPC anyway. The new name "32bit NDR" is similar to the
changed name for the 64bit NDR.
- added an UUID for "bind time feature negotiation" found with Microsoft PDUs.
- added an UUID for "asynchonous MAPI". Of course this UUID/name should be
added to the MAPI dissector, but the MAPI dissector is generated C code from
Samba/OpenChange pidl sources. Eventually those might get updated. An
alternative would be to create a new file to specifically register UUIDs used
in the DCE/RPC context.
- when the g_hash_table_insert() function is used, I've removed the code to
lookup and remove the key, as g_hash_table_insert() is doing that internally
(or more precise, it is overwriting the old value).
- in the dissector function for Bind and BindAck, I now print all context items
into COL_INFO and not just the first one.
- added a new value for Bind results, used by Microsoft products. (The
"Negotiate ACK" is used with the "bind time feature negotiation" UUID)
svn path=/trunk/; revision=39455
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
representation. Use it rather than a raw 0x10.
Add a DREP_ENC_INTEGER() macro that takes a pointer to the data
representation and returns either ENC_LITTLE_ENDIAN or ENC_BIG_ENDIAN;
use it for the encoding argument to proto_tree_add_item(), rather than
just the AND of drep[0] and DREP_LITTLE_ENDIAN, as it's not a boolean
any more, and for string values we'll be supporting character encodings
as well and thus won't be able to trust that the 0x10 bit will mean
"little endian".
Use ENC_NA for some other encoding values, i.e. for FT_BYTES and the
like.
Fix a couple of places in the DCOM dissector where we were passing the
byte-order bit rather than the field value to
proto_tree_add_uint_format().
Clean up white space.
svn path=/trunk/; revision=38128
packet-dcerpc.c:4056:19: error: comparison of integers of different signs:
'guint32' (aka 'unsigned int') and 'int' [-Wsign-compare]
for (i = 0; i < (int) commands_nb; ++i) {
~ ^ ~~~~~~~~~~~~~~~~~
... by removing the "(int)" cast
svn path=/trunk/; revision=35587
I've just finished to write a ncacn_http dissector for Wireshark which
provides the ability to dissect Outlook anywhere packets properly (as
specified by [MS-RPCH].pdf documentation.
svn path=/trunk/; revision=35259
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4422
From me: Fix a number of instances where the function prototype or
the function definition wasn't changed so there was a mismatch
thus causing Windows (but not gcc) compilation errors.
svn path=/trunk/; revision=32365
unaligned unmarshalling of dissectors generated by PIDL.
This will allow us to use PIDL and additional IDLs from the samba
project since they use "noalign" for certain protocols.
This may also allow us to use PIDL to describe, and machinegenerate
dissectors for normal, non-DCERPC, protocols.
This patch for PIDL is still under review, but the PIDL patch is l;ikely
to be committed soonish.
svn path=/trunk/; revision=31583
ABSOLUTE_TIME_LOCAL or ABSOLUTE_TIME_UTC, indicating whether to display
the date/time in local time or UTC. (int)ABSOLUTE_TIME_LOCAL ==
(int)BASE_NONE, so there's no source or binary compatiblity issue,
although we might want to eliminate BASE_NONE at some point and have the
BASE_ values used with integral types start at 0, so that you can't
specify BASE_NONE for an integral field.
svn path=/trunk/; revision=31319
is ndr64 or not, from the bind information to the data we store for each
individual pdu, since the trnasport syntax may change dynamically back
and forth between "normal" and "ndr64" on the same conversation.
svn path=/trunk/; revision=30226
standard ndr transfer syntax from the epm dissector to packet-dcerpc.c
Add a new transfer syntax : ndr64. This is a new syntax with different
scalar sizes and different alignment rules compared to normal ndr.
It is negotiated and used between w2k8 and samba4 boxens and one may
assume, future versions of windows as well.
We need to associate the transfer syntax with the bind information since
the transfer syntax will change the packet encoding rules for the
protocol.
For example, SAMR, as well as all other interfaces support both syntaxes
and are thus encoded differently, wiht different alignments depending on
which transfer was negotioated during the bind.
This will require additional changes to the dcerpc helpers and also to
pidl.
svn path=/trunk/; revision=30209