(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>
==21553==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffbc0b2a5e at pc 0x7fe8684147a3 bp 0x7fffbc0b2950 sp 0x7fffbc0b2948
READ of size 2 at 0x7fffbc0b2a5e thread T0
#0 0x7fe8684147a2 in dissect_schedule_message /home/alagoutte/wireshark-clang/epan/dissectors/packet-gsm_cbch.c:309
#1 0x7fe867ed70a9 in call_dissector_through_handle /home/alagoutte/wireshark-clang/epan/packet.c:512
#2 0x7fe867eda42c in call_dissector_only /home/alagoutte/wireshark-clang/epan/packet.c:2139
#3 0x7fe867ed70a9 in call_dissector_through_handle /home/alagoutte/wireshark-clang/epan/packet.c:512
#4 0x7fe867ed735b in dissector_try_uint_new /home/alagoutte/wireshark-clang/epan/packet.c:1030
#5 0x7fe868a3ebd4 in decode_udp_ports /home/alagoutte/wireshark-clang/epan/dissectors/packet-udp.c:411
#6 0x7fe868a41886 in dissect /home/alagoutte/wireshark-clang/epan/dissectors/packet-udp.c:747
#7 0x7fe867ed70a9 in call_dissector_through_handle /home/alagoutte/wireshark-clang/epan/packet.c:512
#8 0x7fe867ed6d03 in dissector_try_uint_new /home/alagoutte/wireshark-clang/epan/packet.c:1030
#9 0x7fe8684eaa1f in dissect_ip /home/alagoutte/wireshark-clang/epan/dissectors/packet-ip.c:2401
#10 0x7fe867ed70a9 in call_dissector_through_handle /home/alagoutte/wireshark-clang/epan/packet.c:512
#11 0x7fe867ed735b in dissector_try_uint_new /home/alagoutte/wireshark-clang/epan/packet.c:1030
#12 0x7fe868333e98 in dissect_ethertype /home/alagoutte/wireshark-clang/epan/dissectors/packet-ethertype.c:305
#13 0x7fe867ed707d in call_dissector_through_handle /home/alagoutte/wireshark-clang/epan/packet.c:508
#14 0x7fe867eda42c in call_dissector_only /home/alagoutte/wireshark-clang/epan/packet.c:2139
#15 0x7fe8683328ad in dissect_eth_common /home/alagoutte/wireshark-clang/epan/dissectors/packet-eth.c:472
#16 0x7fe867ed70a9 in call_dissector_through_handle /home/alagoutte/wireshark-clang/epan/packet.c:512
#17 0x7fe867ed735b in dissector_try_uint_new /home/alagoutte/wireshark-clang/epan/packet.c:1030
#18 0x7fe868382460 in dissect_frame /home/alagoutte/wireshark-clang/epan/dissectors/packet-frame.c:485
#19 0x7fe867ed70a9 in call_dissector_through_handle /home/alagoutte/wireshark-clang/epan/packet.c:512
#20 0x7fe867eda42c in call_dissector_only /home/alagoutte/wireshark-clang/epan/packet.c:2139
#21 0x7fe867ed5baf in call_dissector /home/alagoutte/wireshark-clang/epan/packet.c:2169
#22 0x7fe867eb6388 in epan_dissect_run_with_taps /home/alagoutte/wireshark-clang/epan/epan.c:329
#23 0x4a0ef9 in process_packet /home/alagoutte/wireshark-clang/tshark.c:3434
#24 0x49c985 in load_cap_file /home/alagoutte/wireshark-clang/tshark.c:3237
#25 0x7fe860e8ede4 in __libc_start_main /build/buildd/eglibc-2.17/csu/libc-start.c:260
#26 0x48586c in _start ??:?
Address 0x7fffbc0b2a5e is located in stack of thread T0 at offset 126 in frame
#0 0x7fe86841353f in dissect_cbch /home/alagoutte/wireshark-clang/epan/dissectors/packet-gsm_cbch.c:345
This frame has 2 object(s):
[32, 80) 'new_slots.i'
[128, 224) 'other_slots.i' <== Memory access at offset 126 underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 ??
svn path=/trunk/; revision=53934
The looping logic is a bit odd, and there was a case where we were never
incrementing any of the multiple loop variables. I suspect the entire function
could be simplified, but this commit fixes the hang and is better suited to
backporting than anything complex.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8730
svn path=/trunk/; revision=49686
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
Tried to provide consistency with GSM dissector (protocol) names, even if the filenames now don't match the dissector name.
svn path=/trunk/; revision=44162
Alexis La Goutte