packet as far as possible, called from both dissect_dnp3_tcp and dissect_dnp3_udp.
Bug: 10287
Change-Id: Iaa988258b3614cb1b408dec41a987fbd61c9727c
Reviewed-on: https://code.wireshark.org/review/3096
Petri-Dish: Graham Bloice <graham.bloice@trihedral.com>
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Reviewed-by: Graham Bloice <graham.bloice@trihedral.com>
accepting a packet as DNP3.
Bug: 10287
Change-Id: I222ec885186447c8a72eaf11cebacff8b9b79fad
Reviewed-on: https://code.wireshark.org/review/3092
Reviewed-by: Graham Bloice <graham.bloice@trihedral.com>
Change-Id: I2ea1892b5963cc5578cbdd2b03029ca8424f2267
Reviewed-on: https://code.wireshark.org/review/2640
Tested-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Change-Id: I24fe3cc4a3589dadc4528a77fe7ff13d06b1a983
Reviewed-on: https://code.wireshark.org/review/2245
Reviewed-by: Michael Mann <mmann78@netscape.net>
Added (hidden) dnp3.addr field set by both source and destination dnp3
addresses to allow easier filtering.
Change-Id: I04980c24c1b9f30a2ee5a0d5ea4ac32ae877504e
Reviewed-on: https://code.wireshark.org/review/908
Reviewed-by: Graham Bloice <graham.bloice@trihedral.com>
Tested-by: Graham Bloice <graham.bloice@trihedral.com>
This corrects a couple issues with the DNP3 Dissector:
- Refactored Read Object String lookups to use value_string
- Corrected issue with multiple object types in a single read not being processed
- Added processing for Direct Operate No ACK Messages
Fixes issues noted in Bug 9839
Change-Id: I9895e509a8d3931c805ce53b718a4951f8f8039e
Reviewed-on: https://code.wireshark.org/review/538
Reviewed-by: Anders Broman <a.broman58@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>
Now that "bytes consumed" can be determined, should tcp_dissect_pdus() take advantage of that?
Should tcp_dissect_pdus return length (bytes consumed)? There are many dissectors that just call tcp_dissect_pdus() then return tvb_length(tvb). Seems like that could all be rolled into one.
svn path=/trunk/; revision=53198
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
Changes include:
- Detect previously-unknown object types. No dissection is attempted of response messages, but at least the types are documented and labelled. As Graham notes, if some examples are provided we can attempt a little more here.
- Change up info_column object label handling to add some of the new objects. Also added in a few that would be present in 'write' messages.
- Add expert info field for abnormal IIN bits. This will help me in my job of detecting unknown objects and unsupported function codes and will easily flag to the user that 'something is up' due to the color changes.
- Only detect Application Layer if we are on the Final Transport Layer frame.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9056
svn path=/trunk/; revision=51768
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
- create/use extended variable string;
- #if 0 unused value_string arrays (instead of marking with _U_);
- "localize" some variable definitions;
- remove some uneeded variable initializers;
- reformat hf[] entries;
- do some whitespace and formatting changes to use a consistent style.
svn path=/trunk/; revision=46236
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
1. Fix time displayed in object values when using relative time from a CTO.
2. Fix some text for IIN flags regarding Outputs in local control
3. Try out DNP3 as a heuristic dissector.
svn path=/trunk/; revision=44486