(unknown length)
this fixes bug 9527
Change-Id: I255ae9662dfeea06e61e4b0891e0ea8eaa254d0f
Reviewed-on: https://code.wireshark.org/review/2462
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Martin Kaiser <wireshark@kaiser.cx>
Change-Id: Ie1a71046b791bcbbf3cf02ddd1c4ddc88b388302
Reviewed-on: https://code.wireshark.org/review/2461
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
tvb_new_subset -> tvb_new_subset_remaining it appears that's what the intention is.
Change-Id: I2334bbf3f10475b3c22391392fc8b6864454de2d
Reviewed-on: https://code.wireshark.org/review/1999
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
If an mp2t packet contains one full subpacket and the fragment of
another one, it happens that the first subpacket will set src or dst to
an ethernet or IP address. Adding the fragment of the second subpacket
will then use this information for calculating the hash in the fragment
table. However, later fragments in other mp2t packets will not have
these info and reassembly will fail.
Change-Id: Ic52763017cb854851b6686654c2d8a1624305d65
Reviewed-on: https://code.wireshark.org/review/1692
Reviewed-by: Anders Broman <a.broman58@gmail.com>
(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
I'm not sold on the name or module the proto_data functions live in, but I believe the function arguments are solid and gives us the most flexibility for the future. And search/replace of a function name is easy enough to do.
The big driving force for getting this in sooner rather than later is the saved memory on ethernet packets (and IP packets soon), that used to have file_scope() proto data when all it needed was packet_scope() data (technically packet_info->pool scoped), strictly for Decode As.
All dissectors that use p_add_proto_data() only for Decode As functionality have been converted to using packet_scope(). All other dissectors were converted to using file_scope() which was the original scope for "proto" data.
svn path=/trunk/; revision=53520
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
In MPEG-related dissectors, "adaption" is used instead of "adaptation" several
times. See patch (it also fixes an unrelated typo that happens to be on the
same line).
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7421
svn path=/trunk/; revision=43539
Martin Kaiser