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
1) The tvb + name (aka. data_source) is only used when the protocol tree is visible
The current implementation of add_new_data_source() doesn't take this into account and simply allocates a data_source regardless. This is what packet_add_new_data_source() tries to rectify.
A couple of dissectors have already been switched over to the new packet_add_new_data_source(). Many are still missing. Help appreciated!
svn path=/trunk/; revision=29427