(or at least the complaints from Valgrind; I couldn't reproduce the crash).
What part of:
~~~
* If you're thinking of using tvb_get_ptr, STOP WHAT YOU ARE DOING
* IMMEDIATELY. Go take a break. Consider that tvb_get_ptr hands you
* a raw, unprotected pointer that you can easily use to create a
* security vulnerability or otherwise crash Wireshark. Then consider
* that you can probably find a function elsewhere in this file that
* does exactly what you want in a much more safe and robust manner.
~~~
did someone not read?
Use tvb_get_ephemeral_stringz() instead of adding (apparently not sufficiently
checked!) offsets to the result of tvb_get_ptr() and assuming that the result
is a) in bounds and b) a NULL-terminated string.
svn path=/trunk/; revision=46577
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
(in some cases by changing proto_tree_add_item() to use
what appears to be the correct 'tree' arg);
Do whitespace cleanup.
svn path=/trunk/; revision=39772
1. If there's no character encoding (ENC_ASCII, ...) specified
then use ENC_ASCII.
2. For all but FT_UINT_STRING, always use ENC_NA
(replacing any existing True/1/FALSE/0
/ENC_BIG_ENDIAN/ENC_LITTLE_ENDIAN).
svn path=/trunk/; revision=39426
Specifically: Replace FALSE|0 and TRUE|1 by ENC_BIG_ENDIAN|ENC_LITTLE_ENDIAN as
the encoding parameter for proto_tree_add_item() calls which directly reference
an item in hf[] which has a type of:
FT_UINT8
FT_UINT16
FT_UINT24
FT_UINT32
FT_UINT64
FT_INT8
FT_INT16
FT_INT24
FT_INT32
FT_INT64
FT_FLOAT
FT_DOUBLE
svn path=/trunk/; revision=39288
Metadata Blocks in the bundle protocol (DTN) can contain EID references. These
are not considered by the current implementation and following blocks are
parsed wrong. The attached patch solves this bug and increment the offset as
much as needed to skip the EID references.
svn path=/trunk/; revision=38448
Also: Significant code rework including:
- Fix bug wherein a timestamp was incorrectly reported as being an Error;
- Replace many proto_tree_add_text()/proto_item_set_text() sequences each by a
single proto_tree_add_text().
- remove unneeded #include <string.h>
- Whitespace clanup including replacing mixed space/tab indentation by spaces.
svn path=/trunk/; revision=36437
keys to have _uint in their names, to match the routines that handle
dissector tables with string keys. (Using _port can confuse people into
thinking they're intended solely for use with TCP/UDP/etc. ports when,
in fact, they work better for things such as Ethernet types, where the
binding of particular values to particular protocols are a lot
stronger.)
svn path=/trunk/; revision=35224
argument indicating whether to include the time zone in the string. If
we're constructing a display filter, don't include the time zone,
otherwise do. Fixes bug 4756.
svn path=/trunk/; revision=32913
date as YYYY/DDD, where DDD is a 1-origin day of year. Move the formats
to a "time_fmt.h" file, included by the headers that use it. Have
abs_time_to_str() and abs_time_secs_to_str() take the date format value,
rather than a Boolean "show this as UTC" flag, as an argument. Document
the ABSOLUTE_TIME_ formats a bit better. Use that format in the CCSDS
and VCDU dissectors, rather than having those dissectors do the
formatting themselves.
svn path=/trunk/; revision=32034
indicating whether the time should be shown as local time or UTC. For
now, always pass FALSE, meaning "show as local time".
Clean up some stuff in the SNMP dissector, use abs_time_secs_to_str()
for times with one-second resolution, and update a comment in various
macros in the WSP dissector, while we're at it.
svn path=/trunk/; revision=31227
The primary header in bundle protocol contains some offset values(destination
scheme offset, destination ssp offset, source scheme offset, source ssp offset,
etc). These are the offsets within the dictionary if the length of the
dictionary length is greater than 0. But if the dictionary length is 0, then
these offset refer to node number and service number respectively(according to
compressed bundle header encoding). For example if destination scheme offset is
2 and the destination ssp offset is 1, then the destination
EID(<node_number>.<service_number>) is 2.1.
Currently the dtn dissector will consider these offsets to be actual offsets in
the dictionary even if the dictionary length is 0. So the values for the
EID's(destination, source, report, custodian) and their schemes are junk
values. For example if the destination scheme offset is 2 and the destination
ssp offset is 1 and the dictionary length is 0(which means the dictionary is
empty), then the destination scheme is 2 bytes after the beginning of the
metadata block(field after dictionary) and destination is 1 byte after the
beginning of the metadata block.
svn path=/trunk/; revision=30682
display_metadata_block() return 0 (meaning they failed to decode something and
the offset was not incremented) rather than checking if the resulting offset
is 0.
This fixes the infinite loop reported in:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4156
svn path=/trunk/; revision=30672
SDNVs are theoretically unlimited in size. The value of most SDNVs in the
Bundle Protocol is practically limited to far less than a 32 bit number. The
initial dissector included only 1 SDNV evaluation routine which returned a 32
bit number. SDNV fields that evaluated to greater than a 32 bit number were
considered in error. One BP implementation chose to add some syntax to one of
the SDNV fields that extends it to more than 32 bits. The patch included here
adds an evaluation routine that will return a 64 bit number. That routine is
called to evaluate the field where it makes sense to have a value in excess of
32 bits.
svn path=/trunk/; revision=29954
Within the attached diff file are two source files, packet-dtn.h and
packet-dtn.c. Their function is to decode Bundle Protocol PDUs sent using the
UDP or TCP Convergence Layers. These protocols have been released by the
Internet Research Task Force and are described in RFC 4838 and RFC 5050.
Detailed information on DTN can be obtained at www.dtnrg.org.
svn path=/trunk/; revision=29010