I'm not sold on the name or module the proto_data functions live in, but I believe the function arguments are solid and gives us the most flexibility for the future. And search/replace of a function name is easy enough to do.
The big driving force for getting this in sooner rather than later is the saved memory on ethernet packets (and IP packets soon), that used to have file_scope() proto data when all it needed was packet_scope() data (technically packet_info->pool scoped), strictly for Decode As.
All dissectors that use p_add_proto_data() only for Decode As functionality have been converted to using packet_scope(). All other dissectors were converted to using file_scope() which was the original scope for "proto" data.
svn path=/trunk/; revision=53520
The script didn't catch as many as I would have liked, but it's a start.
The most common (ab)use of proto_tree_add_uint_format was for appending strings to CRC/checksum values to note good or bad CRC/checksum.
svn path=/trunk/; revision=52045
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
Cast away some implicit 64-bit-to-32-bit conversion errors due to use of
sizeof.
Cast away some implicit 64-bit-to-32-bit conversion errors due to use of
strtol() and strtoul().
Change some data types to avoid those implicit conversion warnings.
When assigning a constant to a float, make sure the constant isn't a
double, by appending "f" to the constant.
Constify a bunch of variables, parameters, and return values to
eliminate warnings due to strings being given const qualifiers. Cast
away those warnings in some cases where an API we don't control forces
us to do so.
Enable a bunch of additional warnings by default. Note why at least
some of the other warnings aren't enabled.
randpkt.c and text2pcap.c are used to build programs, so they don't need
to be in EXTRA_DIST.
If the user specifies --enable-warnings-as-errors, add -Werror *even if
the user specified --enable-extra-gcc-flags; assume they know what
they're doing and are willing to have the compile fail due to the extra
GCC warnings being treated as errors.
svn path=/trunk/; revision=46748
Label the data sources for reassembled fragments as "Reassembled
6LoWPAN".
Fix the capitalization of "6LoWPAN".
Also, label the data sources for decompressed fragments as "Decompressed
6LoWPAN xxx".
svn path=/trunk/; revision=45529
Label the data sources for them as "6LoWPAN xxx", where "xxx" is the
type of compression, and label the data sources for reassembled
fragments as "Reassembled 6LoWPAN".
Fix the capitalization of "6LoWPAN".
Note that if reassembly fails, continuing dissection is not the right
thing to do, at least not if it failed because we don't *yet* have all
the fragments.
svn path=/trunk/; revision=45527
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
Also (for a few files):
- create/use some extended value strings;
- remove unneeded #include files;
- remove unneeded variable initialization;
- re-order fcns slightly so prefs_reg_handoff...() at end, etc
svn path=/trunk/; revision=44438
The 6LoWPAN dissector had as a TODO the 'stateful address compression' mode.
This patch fixes that TODO, up to HC-13.
This patch also updates to HC-08, where the PANID is no longer used in forming
the short address.
svn path=/trunk/; revision=34290
The committed changes in 33624 did not include all fixes of the previous patch
file - Please add the fix for the field description of the 8-bit Deep Hops Left
field
Attached file contains this fix (+as well as small correction to the field
descriptions of V and F flags, according to the terminology of RFC 4944)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5047
svn path=/trunk/; revision=33630
packet-6lowpan.c dissects the non-compressed ipv6 fields in an order different
from the one specified in RFC 4944 §10.3.1.
The patch fixes the wrong order and an additional problem with the dissection
of the mesh header: support for the Deep Hops Left field (RFC 4944 §5.2)
svn path=/trunk/; revision=33624
of a structure being an empty array; that is *not* supported by all the
compilers that can be used to build Wireshark).
svn path=/trunk/; revision=32412
I've come across a bug in the 6LoWPAN header decompression code that
incorrectly computes the length of IPv6 extension headers by adding the
protocol and length fields twice.
svn path=/trunk/; revision=32157
This patch fixes 6LoWPAN fragmentation to comply with RFC4944.
I also happened across a problem with the derivations of
interface identifiers from 16-bit IEEE 802.15.4 addresses, which
should also be fixed in my patch.
svn path=/trunk/; revision=32155
This patch fixes a bug in the 6LoWPAN dissectors that corrupts addresses when
multicast address compression is used. Testing this fix also uncovered a bug in
the computation of the length of the extension headers. And some typos.
svn path=/trunk/; revision=31870
This patch fixes a bug in the 6LoWPAN dissector where link-local addresses
created from an EUI-64 address do not correctly invert the universal/local bit
as recommended by section 4 of RFC2464.
svn path=/trunk/; revision=31843
When a 6lowpan message has a compressed UDP length (i.e. the length must be
calculated, not read from the headers), the 6lowpan dissector correctly reports
that the UDP length is compressed, but it may try to read the length from the
headers anyway.
svn path=/trunk/; revision=31075
We've discovered a number of bugs in the 6LoWPAN dissector,
and have fixed them in the following patch. The fixed bugs include:
- Incorrect UDP Checksum calculation.
- Incorrect link-local prefix when decompressing IPHC headers.
- Incorrect parsing of the UDP port numbers when not 8-byte aligned.
- Overflow of the datagram offset field when reassembling fragmented packets.
svn path=/trunk/; revision=30840
The attached patch adds a dissector for IPv6 over IEEE 802.15.4 (aka 6LoWPAN).
The protocol is specified in RFC 4944. This dissector also processes the
6LoWPAN draft header compression scheme in draft-ietf-6lowpan-hc-05.
svn path=/trunk/; revision=30268
Michael Mann