Do not try to recover from truncated tvbs for fragment_add_seq-like
functions:
- If it is the first block and the dissector requested frag_data_len
number of bytes, we should not lie and pretend that we are fully
reassembled.
- For other blocks, returning NULL as no reassembly was possible makes
sense. But other fragments in the list should not be cleared as there
may be partial fragments which were returned before.
It seems that this special behavior was introduced in
b2c11b5e13 (freeing fragments and
returning NULL as an optimization when fragments are deemed not needed
anymore) and faeb2c2ee1 (for returning
fd_head for the first fragment, "so the first fragment gets dissected as
fragmented packet").
Now in theory unused fragments could stick around, but that also
possible with the normal fragment_add functions.
Bug: 11799
Change-Id: I20829c54e1b2eee25a91fe4de51b19b1458c7789
Reviewed-on: https://code.wireshark.org/review/14082
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Try to improve address API and also fix some constness warnings
by not overloading the 'data' pointer to store malloc'ed buffers
(use private pointer for that instead).
Second try, now passing test suite.
Change-Id: Idc101cd866b6d4f13500c9d59da5c7a38847fb7f
Reviewed-on: https://code.wireshark.org/review/13946
Petri-Dish: João Valverde <j@v6e.pt>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: João Valverde <j@v6e.pt>
Documentation changes only (comments and docbook).
Update WSDG with the fragment_add_seq_check API that was introduced in
Wireshark 1.10.
Fix typos and clarify the many functions we have for adding reassembling
fragments.
Change-Id: I38715a8f58e9cf1fe3e34ee4b1a4ae339630282b
Reviewed-on: https://code.wireshark.org/review/14066
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
That leaves less room for getting it wrong.
Change-Id: Iea003fc102ccd14db2924b70fc685033ca34f291
Reviewed-on: https://code.wireshark.org/review/13863
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This reverts commit 13ec77a9fc.
This commit introduces a segmentation fault for Lua code (uncovered by the test suite).
Change-Id: Ibc273d1915cda9632697b9f138f0ae104d3fb65e
Reviewed-on: https://code.wireshark.org/review/13813
Reviewed-by: João Valverde <j@v6e.pt>
Try to improve 'address' API (to be easier/safer) and also avoid
some constness warnings by not overloading the 'data' pointer to
store malloc'ed buffers (use private pointer for that instead).
Change-Id: I7456516b12c67620ceadac447907c12f5905bd49
Reviewed-on: https://code.wireshark.org/review/13463
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: João Valverde <j@v6e.pt>
That removes most of the uses of the frame number field in the
frame_data structure.
Change-Id: Ie22e4533e87f8360d7c0a61ca6ffb796cc233f22
Reviewed-on: https://code.wireshark.org/review/13509
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Fixes memleak in reassemble.c
480 bytes in 60 blocks are definitely lost in loss record 3,010 of 3,059
at 0x4C28C10: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0xADA3328: g_malloc (in /usr/lib/libglib-2.0.so.0.4600.1)
by 0xADBA512: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.4600.1)
by 0x6575C7D: fragment_reassembled (reassemble.c:804)
by 0x6577785: fragment_add_seq_check_work (reassemble.c:2027)
by 0x6577880: fragment_add_seq_next (reassemble.c:2068)
by 0x6E614E6: dissect_sccp_message (packet-sccp.c:2875)
by 0x6E63641: dissect_sccp (packet-sccp.c:3401)
by 0x6546CF7: call_dissector_through_handle (packet.c:620)
by 0x6546EA1: call_dissector_work (packet.c:706)
by 0x6547A04: dissector_try_uint_new (packet.c:1163)
by 0x6547A65: dissector_try_uint (packet.c:1189)
Change-Id: I0117b48e1e5d5688c49f264f24387dd6de1d6e08
Reviewed-on: https://code.wireshark.org/review/11541
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
It ends up dragging in libwireshark headers, which programs not linking
with libwireshark shouldn't do. In particular, including
<epan/address.h> causes some functions that refer to libwireshark
functions to be defined if the compiler doesn't handle "static inline"
the way GCC does, and you end up requiring libwireshark even though you
shouldn't require it.
Move plurality() to wsutil/str_util.h, so that non-libwireshark code can
get it without include epan/packet.h. Fix includes as necessary.
Change-Id: Ie4819719da4c2b349f61445112aa419e99b977d3
Reviewed-on: https://code.wireshark.org/review/11545
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Replace CMP_ADDRESS, COPY_ADDRESS, et al with their lower-case
equivalents in the asn1 and epan directories.
Change-Id: I4043b0931d4353d60cffbd829e30269eb8d08cf4
Reviewed-on: https://code.wireshark.org/review/11200
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Trust that the files in epan/ immediately (not dissectors) know what they're
doing so just blindly convert them to captured length.
Change-Id: I872f7d58b2e15ae82c75fd56f4873996fbc97be7
Reviewed-on: https://code.wireshark.org/review/9083
Reviewed-by: Evan Huus <eapache@gmail.com>
Question: "what if we didn't capture the entire fragment due to a too-short
snapshot length?"
Answer: An assertion fails and we leak a bunch of memory.
Don't do that.
Bug: 11129
Change-Id: I0adfb217f0e66ae8f5f6255a4caf7ff940826b59
Reviewed-on: https://code.wireshark.org/review/8128
Petri-Dish: Evan Huus <eapache@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Evan Huus <eapache@gmail.com>
frame
but in different SCTP DATA chunks, whitout the patch the message is
reassembled in both chunks leading to duplicated upper layer PDU:s in the
frame.
Change-Id: Ie31142c38c728018178947544b571622447d8e8f
Reviewed-on: https://code.wireshark.org/review/7716
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Also add an assertion to tvb_generic_clone_offset_len so that it throws an
error *before* allocating memory, as otherwise that memory is leaked.
Bug: 10474
Change-Id: I5036cefac16841914a59670c64979cf599bf7969
Reviewed-on: https://code.wireshark.org/review/4234
Petri-Dish: Evan Huus <eapache@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Evan Huus <eapache@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>
Instead of incrementing the offset for each new segment by one we add the length of the segment so that each segment is correctly shown in the segment list.
It proves to be very useful to find which packet (segment) is causing an application dissector to go wrong.
From Matthieu Patou
svn path=/trunk/; revision=53118
much, but I think this way's a little clearer, and it made it much easier to
figure out where the memory leak was.
Fixes the leaks from https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9243
svn path=/trunk/; revision=52448
- support merging chains in tvb_add_to_chain
- when we have an old reassembled TVB, just merge the chains rather than
freeing it (we may still need it as it may already be a data source)
- modelines
Fixes https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9027
#BACKPORT, but it's gonna be messy...
svn path=/trunk/; revision=51825
this code as C++.
Make pointers to raw packet data pointers to guint8, not pointers to
char, as they're octets, not characters.
svn path=/trunk/; revision=50583
revisit this reassembly (in a multi-pass program such as Wireshark, or
TShark with -2), we'll throw the same error.
In fragment_set_tot_len(), allow the length to be set to a value that's
before the offset of existing fragments; we'll catch that later when the
reassembly completes. This lets us handle some problems with DTLS less
confusingly.
When adding frames to an already-completed reassembly, check for
fragments that overlap existing fragments or go past the end of the
reassembly, and report errors.
When completing a reassembly, make the buffer for the reassembled data
big enough to contain the specified data length for the reassembly, even
if that's less than the offset + length of the last fragment. Flag all
fragments that go past that length as "too long", and only copy out what
part of them fits, if any. That lets us flag the correct fragment or
fragments as being "too long".
When adding fragments, do some additional checks, even if we're not
doing the first pass through the packets, so errors that show up in the
first pass also show up on subsequent passes.
svn path=/trunk/; revision=48909
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
Peter Wu