list rather than duplicating this information in the dissector. Some
of the opnum strings were starting to get out of date as developers
forgot to update the information in both places.
svn path=/trunk/; revision=7936
the same value, as an open might return handle XXX, handle XXX might
then be closed, and a subsequent handle might return handle XXX, and we
want to keep the two handles distinct to avoid, for example, displaying
handles closed before they're opened.
In policy handle open replies, store the handle name only if the
operation succeeded. We can now do that without parsing the packet
twice.
Have "dissect_nt_policy_hnd()" optionally return, through a pointer, the
protocol tree item for the handle, so that its caller can decorate the
item with the name of the handle - that's done on opens, where we do
that only if the operation succeeds.
svn path=/trunk/; revision=7787
appears to be a 4-byte aligned quantity, with the other 2 bytes
presumably seen by whoever added the code to dissect those 6 bytes
being, most likely, padding to align the 4-byte quantity.
svn path=/trunk/; revision=7660
"dissect_ndr_char_cvstring()" and "dissect_ndr_wchar_cvstring()", to
indicate that they're for conformant varying strings.
Rename "dissect_ndr_character_array()" to "dissect_ndr_cvstring()", to
indicate that it's for conformant varying strings.
svn path=/trunk/; revision=7096
Rename "dissect_ndr_element_array()" to "dissect_ndr_character_array()",
move it out of "packet-dcerpc-nt.c" to "packet-dcerpc.c", and have it
use the standard DCE RPC array max count/offset/count fields rather than
their own private versions of those fields. Give it an option to create
a subtree, and an argument to specify the field to use for the actual
data buffer, and export it.
Move the routines for handling arrays of "char" and "wchar" as strings
out of "packet-dcerpc-nt.c" to "packet-dcerpc.c".
Add a routine to handle an array of "char" as an opaque blob of bytes.
Use "dissect_ndr_character_array()" to dissect character strings in MAPI
(the strings in question are ASCII, not Unicode), and use the routine to
handle an array of "char" as an opaque blob of bytes to dissect
encrypted data (again, it's bytes, not 16-bit quantities). Show them as
encrypted data, not unknown data.
Use "dissect_ndr_character_array()" to dissect a form name in
"dissect_form_name()" in the SPOOLSS dissector.
svn path=/trunk/; revision=7091
belongs, as that's redundant.
Fix a bunch of cases where that was done, and map the old name to the
new name.
Instead of marking "mtp3.mtp3_standard" as obsolete, map it to
"mtp3.standard".
svn path=/trunk/; revision=7030
Strings that used to call with levels != -1 should call the
callback helper which will append the string to the pointer item.
svn path=/trunk/; revision=7017
pointers.
The first argument to "sscanf()" is a "const char *"; don't cast const
pointers to "char *" when passing them to "sscanf()".
Assign the result of "tvb_get_ptr()" to const pointers, not non-const
pointers.
Make the "pdata" argument to various DCE routines a const pointer.
svn path=/trunk/; revision=6688
If we had unreassebled DCERPC PDUs but had
decryption of MAPI enabled we would try to read too much data from the
tvbuff and ethereal would later dump core.
svn path=/trunk/; revision=5673
in the "packet_info" structure instead, as we don't need a pointer for
every single frame in the capture file, just for each frame for which we
currently have an open "epan_dissect_t".
svn path=/trunk/; revision=5614
"int" constant becomes "int", and comparing that with "unsigned int"
gives a "signed vs. unsigned comparison" warning, even though the "int"
constant in question is positive).
svn path=/trunk/; revision=5559
The function request/call are dissected but the main body of the function
in/out parameters consists of a unidimensional conformant and varying array of bytes which content is encrypted/obfuscated.
Whoever can tell me how to decrypt/unobfuscate these bytes will get
a case of VB next time in Sydney.
svn path=/trunk/; revision=5532