If there are 8-bit "extended ASCII" encodings, either one should be
wired in or there should be a preference for them.
Change-Id: Id62381b2579e8edf3719bd92959821c21f7ba223
Reviewed-on: https://code.wireshark.org/review/402
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Also, note that the "8-bit" encoding is "user-defined".
Change-Id: Ic4786873150d837d8793d2d3d20af50cd0003cc7
Reviewed-on: https://code.wireshark.org/review/399
Reviewed-by: Guy Harris <guy@alum.mit.edu>
declares the functions must be included, in order to make sure the
declarations match the function signature. Make it so.
They *didn't* match; fix that.
Do *not* use 16-bit tvbuff offsets; there is no advantage to that (and,
in fact, 32-bit arithmetic may be easier on some platforms), and it has
the disadvantage that you're more likely to have the offset overflow.
dissect_cbs_serial_number() returns the new offset, not the length of
the item it dissected; don't add its return value to the offset, set the
offset to its return value.
Make dissect_cbs_message_identifier() return the new offset as well, for
consistency, and don't add *its* return value to the offset.
svn path=/trunk/; revision=54714
was done using textual search+replace, not anything syntax-aware, so presumably
it got most comments as well (except where there were typos).
Use a consistent coding style, and make proper use of the WS_DLL_* defines.
Group the functions appropriately in the header.
I ended up getting rid of most of the explanatory comments since many of them
duplicated what was in the value_string.c file (and were out of sync with the
recent updates I made to those in r48633). Presumably most of the comments
should be in the .h file not the .c file, but there's enough churn ahead that
it's not worth fixing yet.
Part of https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8467
svn path=/trunk/; revision=48634
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
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
