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
No, ReportedBoundsError is not the right thing to throw, ReassemblyError is.
That's why I added it in the first place!
svn path=/trunk/; revision=48123
instead of using DISSECTOR_ASSERT. When a dissector passes bad data to the
reassembly machine, that isn't necessarily the dissector's fault - the data may
come straight from the packet, and the dissector may not have enough information
to know it's bad without telling the reassembly machine in the first place.
Also fix a bug in the reassembly machine. If it were given a fragment and all of
the following conditions were met:
- the other associated fragments were already marked as done (reassembled)
- the fragment went beyond the end of the conceptual reassembled buffer
- the dissector had not set the PARTIAL_REASSEMBLY flag
then the reassembly machine would incorrectly think there was an overlap and
run past the end of the already-reassembled buffer.
Should fix the rest of
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8380
#BACKPORT
This is probably too big and intrusive to backport directly, and parts of it
will need adapting anyways since reassemble.c has changed. But the bug exists
and crashes in 1.6 and 1.8, so we'll have to do something.
svn path=/trunk/; revision=48011
sanity checks before setting a packet's total length in
fragment_set_tot_len()
(from me: check if fragments exist for the given id)
hopefully, this fixes#8111 and #8163 without causing troubles for other
protocols that use fragmentation and reassembly
svn path=/trunk/; revision=46999
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
make Save-As/Displayed/All-Packets save not only the displayed packets but
also any other packets needed (e.g., for reassembly) to fully dissect the
displayed packets.
This works only for the "All packets" case; choosing only the Selected packet,
the Marked packets, or a range of packets would require actually storing which
packets depend on which (too much memory) or going through the packet list many
times (too slow). Also, this behavior is always the case: you can't save the
displayed packets without their dependencies (I don't see why this would be
desirable).
So far this is done for SCTP and things using the reassembly routines (TCP has
been tested).
The Win32 dialog was modified but hasn't been tested yet.
One confusing aspect of the UI is that the Displayed count in the Save-As
dialog does not match the number of displayed packets. (I tried renaming the
button "Displayed + Dependencies" but it looked too big.) The tooltip tries
to explain this and the fact that this works only in the All-Packets case;
suggestions for improvement are welcome.
Implementation details:
Dissectors (or the reassembly code) can list frames which were needed to
build the current frame's tree. If the current frame passes the display
filter then each listed frame is marked as "depended upon" (this takes up the
last free frame_data flag).
When performing a Save-As/Displayed/All-Packets then choose packets which
passed the dfilter _or_ are depended upon.
svn path=/trunk/; revision=41216
in README.devloper. Remove g_gnuc.h since it's no longer needed. Remove
tvbuff_init(), tvbuff_cleanup(), reassemble_init(), and
reassemble_cleanup() since they were only used for older GLib versions
which didn't support GSlices. Assume we always support the "matches"
operator.
svn path=/trunk/; revision=37978
http://www.wireshark.org/lists/wireshark-dev/200910/msg00074.html
g_slice allocing the keys should make it possible to walk the
fragment table and free the fragments once they are g_slice_alloced.
It remains fo figure out how to do that.
svn path=/trunk/; revision=37112
current fragment pushes us past the reassembled size: it may be that the
current fragment is a duplicate/retransmission and will be ignored.
Also, if we detect a conflict between a previous and the current fragment,
flag the current (conflicting) fragment as FD_OVERLAPCONFLICT. Do *not* flag
the fragment that got us into the reassembly routine (probably the final
fragment): it is not (may not be) the guilty fragment.
Clean up some spacing.
Also add reassembly tests for duplicate/retransmitted fragments.
svn path=/trunk/; revision=36131
the data source does not need to be allocated if (!tree).
Rev 30158 took the if (!tree) check out indicating that the check was invalid.
So: (since packet_add_new_data_source() now only calls add_new_data_source()),
remove packet_add_new_data_source().
svn path=/trunk/; revision=34717
compiling again.
fragment_add_seq_check(), fragment_add_seq_802_11(), and fragment_add_seq_next()
all call fragment_add_seq_check_work() so make their prototypes match each other
in const-ness. This fixes a warning when compiling reassemble_test.
svn path=/trunk/; revision=32933
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
- it contains pointers to a couple malloc()'d addresses
- it is inserted in the fragment table (the contents of which are
g_free()'d in free_all_fragments())
Instead, do like fragment_key_copy() and use a g_slice or g_chunk, depending
on the glib version.
svn path=/trunk/; revision=30599
Guy Harris