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
fragmented data without adding an empty data fragment.
This is used by the RTSE dissector which can't identify the
last fragment until after it has been added.
svn path=/trunk/; revision=22174
01_reassemble_test.patch
------------------------
I didn't want to do anything without some unit tests, so here they are.
This allows a standalone binary, epan/reassemble_test, to be built; this can be run from the commandline and should end up printing out "success"
if all goes well.
NOTE the changes to makefile.am NOT checked in currently.
Incidentally: is it possible to get the buildbot to run things like this, exntest and tvbtest?
02_reassemble_refactor.patch
----------------------------
fragment_add_seq, fragment_add_dcerpc_dg and fragment_add_seq_check_work were all pretty much carbon-copies of each other. This patch factors out the common parts of the routines into a new routine, fragment_add_seq_key().
03_reassemble_partial_reassembly.patch
---------------------------------------
This makes fragment_set_partial_reassembly() work for datagrams assembled with fragment_add_seq(). The patch itself is actually quite small, but it adds another unit test which is reasonably lengthy.
svn path=/trunk/; revision=20888
having been reassembled.
Fix the comments in reassembly.c and reassembly.h regarding what the reassembly
routines actually return in the 802.11 and no-sequence-number cases when they
are given the first and last packet (that is, a non-segmented packet): in
particular the routines return a pointer to a list containing just the one
fragment.
svn path=/trunk/; revision=20505
add a check to fragment_add_common() if the given tvb parameters are ok, otherwise throw a DissectorError
add some more symbols to libethereal.def
svn path=/trunk/; revision=17073
Find attached a couple of changes for t38:
- Use the dissector to reassemble t30 frames
- Dissect t30 protocol
- Move the "Fax t38 analysis" to the "VoIP Calls". Now when selecting
"Statistics"->"Fax t38 analysis" option, there is a message that
redirect the user to use the "Voip calls" instead. We may keep this
option for one release, and then remove it ?
- Added in the "Voip calls" the ability to detect a t38 call if there
are not signaling associated with it. For example, when using "Decode
as.." to dissect t38 packets, it is possible to use the "Voip calls" to analyze that call.
- Display "SDP (t38)" in the "Voip calls graph" for SDP t38 sessions.
Regards
Alejandro Vaquero
svn path=/trunk/; revision=17033
in addition, I had to implement fragment_get_reassembled() in addition to fragment_get(), which works with reassembled_table
svn path=/trunk/; revision=15762
as connection oriented (cn) and connectionless (dg) DCE/RPC uses different ways to handle defragmentation and this function is only used for dg
svn path=/trunk/; revision=15757
reassemble.c:
I had to change the way the reassemble code works if the dissector is telling that more fragments *will* follow. In this case the reassemble code shouldn't try to reassemble already at that time ...
I've also changed the way if a fragment was already seen or not, as it's not enough to check for the frame number, in the scenario described above.
Unfortunately both changes *might* broke other protocols from reassemble properly. I've checked with excessive TCP desegmentation and it's still working without any changes :-)
packet-dcerpc.c:
use a tvb subset to limit the "end of bytes" processed in a single fragment dissect run, as each fragment has it's own DCE/RPC header (and isn't part of the stub data of the previous packet).
svn path=/trunk/; revision=15744
dissector says "sorry, I need even more data in this packet", don't flag
that packet as being reassembled in that frame. Indicate that we should
perhaps do all the "partial reassembly" stuff in
"fragment_set_partial_assembly()", which would obviate the need for the
hack in the TCP dissector.
Clean up indentation.
svn path=/trunk/; revision=15139
FD_NOT_MALLOCED set, has to be copied - all FD_NOT_MALLOCED means is
that the fragment's data is part of the old reassembled data, rather
than a malloced chunk of its own (this happens if, after reassembly, the
dissector says more reassembly is necessary, as can happen, for example,
in the case of HTTP and other protocols where reassembly continues until
a terminator is seen). Not copying the data means that the reassembled
data is, in part, whatever random junk happens to be in the
newly-allocated buffer.
Back out the change not to copy the data, but add some sanity checks, in
the hopes of preventing the crash that caused the change not to copy the
data to be added, and in the hopes of discovering the ultimate source of
that crash and fixing it.
svn path=/trunk/; revision=15057
Kovarththanan Rajaratnam