In RTPS, regular samples are serialized with the format
<encapsulation, serialized data> and thus, the dissection of the
encapsulation was suggested to be done in the custom dissector.
However, batches are serializing the encapsulation only once as
<encapsulation, sample 1, sample 2>. This makes us need to dissect
the encapsulation in the RTPS dissector and providing as (void*) data
to the custom dissector. This way we support the regular samples
dissection as well as the batches dissection.
I have defined rtps_dissector_data in packet-rtps.h and I suggest
we include that header file when we want to write a custom dissector.
Bug: 12029
Change-Id: I74ed4c31484f9a99ad6c44c6c34cc52be2adb7c8
Reviewed-on: https://code.wireshark.org/review/13413
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Multi-path mutation responses can have a variable number of values
encoded in them:
- Successful requests have 0..N values, one for each mutation which
wishes to return a value (e.g. SUBDOC_COUNTER)
- Unsuccessful requests have 1 value, specifying the index and status
of the first failing mutation
Add support for decoding a variable number of response values.
Change-Id: Ia1f682f7f701829bd808a44ee142ffe912095e15
Reviewed-on: https://code.wireshark.org/review/13688
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
1. ENIP: When there is more than one ENIP command in a given TCP packet, display both in the Info column. Previously, only 1 would be displayed.
2. CIP: Services need a context to be able to interpret properly. Display the Class or Symbol name in the Info column in an object oriented manner for Request Paths, or Connection Paths.
3. CIP: Display the request path/service in a CIP response, instead of just "Success". These changes make it visually easier to identify traffic.
4. CIP: For the Info column, make Multiple Service Packet formatting a little more consistent regarding the divider between embedded packets. Previously, it would display 2 different separator types "," and "|".
5. CIP: Add preference to enable/disable "Display enhanced Info column data"
Change-Id: I7e95bc144588c0925137e01abbc814babb494d19
Reviewed-on: https://code.wireshark.org/review/13632
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Userlog is user flow logs of H3C device.
Flow logging records users' access to the extranet. The device classifies and
calculates flows through the 5-tuple information, which includes source IP address,
destination IP address, source port, destination port, and protocol number,
and generates user flow logs. Flow logging records the 5-tuple information of
the packets and number of the bytes received and sent. With flow logs, administrators
can track and record accesses to the network, facilitating the availability and
security of the network.
examplecapture: https://wiki.wireshark.org/SampleCaptures#UserLog
Bug: 11878
Change-Id: If3b5ca75bdd6cd8dc12af4a35401c5a6aa193a73
Reviewed-on: https://code.wireshark.org/review/8148
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
'openflow.ofp_match.pad' exists multiple times with NOT compatible types: FT_UINT16 and FT_BYTES
Change-Id: I514bdf6a77ddbf9f8d7e614ea6f4ecf04a664453
Reviewed-on: https://code.wireshark.org/review/13677
Reviewed-by: Anders Broman <a.broman58@gmail.com>
'ospf.mpls.bc' exists multiple times with NOT compatible types: FT_FLOAT and FT_UINT8
'ospf.v3.lsa.link_local_interface_address.ipv6' exists multiple times with NOT compatible types: FT_IPv4 and FT_IPv6
Change-Id: I6a014c072c05bdb30ae30d56a6718062fccc75c7
Reviewed-on: https://code.wireshark.org/review/13681
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: I58192af77c8e9af94183e5d82d282e22dc91b49e
Reviewed-on: https://code.wireshark.org/review/13659
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Bug: 11933
Change-Id: I7ac03166c4c69a2366da26c44a89aee60116ac7f
Reviewed-on: https://code.wireshark.org/review/13674
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
parsing
Change-Id: I55d0b435ae1b12e14a20dd9ea18ba05188b0e378
Signed-off-by: Francesco Fondelli <francesco.fondelli@gmail.com>
Reviewed-on: https://code.wireshark.org/review/13666
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Don't just display every field that's not a STRING as a lump of hex
bytes; display them (and make them filterable) according to their data
type.
Change-Id: I5717c45bc970616ba9438277e1bcaae46c3cbdf8
Reviewed-on: https://code.wireshark.org/review/13669
Reviewed-by: Guy Harris <guy@alum.mit.edu>
the code in question deals with the scenario where the length field's
value is larger than the number of remaining bytes
we can simply stop the dissection if truncation of the data is expected
if not, we continue disecting and we'll get an exception when we reached
the end of the data...
Change-Id: I3f29df694d9ea7d41f19511d267ef6b785527e3c
Reviewed-on: https://code.wireshark.org/review/13624
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
into consideration.
This makes it possible to differentiate between packets on different
vlans and can be expanded to handle tunnels.
Change-Id: Id36e71028702d1ba4b6b3047e822e5a62056a1e2
Reviewed-on: https://code.wireshark.org/review/13637
Reviewed-by: Anders Broman <a.broman58@gmail.com>
(The routing token/cookie needs to be dissected better.)
Change-Id: I33464a846cda711aa430ba8f71dfe1959de3b7f9
Reviewed-on: https://code.wireshark.org/review/13651
Reviewed-by: Guy Harris <guy@alum.mit.edu>
packet-ositp.c is more complete and is what's used, so we don't need
packet-x224.c.
Change-Id: Id3409d7b2af0e4ecbc64c74bb6d1ed9ea8f31738
Reviewed-on: https://code.wireshark.org/review/13650
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Add tables for heuristic dissectors, and add dissectors for the stuff
Microsoft puts there for RDP; they're violating the COTP spec, but I
guess they're stuck because they're using TP0, which doesn't support
user data.
While we're at it, add variants of proto_tree_add_bitmask() and
proto_tree_add_bitmask_flags() that return the bitmask, for use by
callers.
A side-effect of the change is that the proto_tree_add_bitmask routines
no longer treat the encoding as a Boolean, so we have to pass
ENC_LITTLE_ENDIAN or ENC_BIG_ENDIAN, not just some non-zero or zero
value. Do so.
Rename ositp_decode_CC() to ositp_decode_CR_CC(), to note that it
decodes both CR and CC PDUs.
Bug: 2626
Change-Id: If5fa2a6dfecd9eb99c1cb8104f2ebceccf1e57c2
Reviewed-on: https://code.wireshark.org/review/13648
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Change-Id: I3c55af73ba989080cf6dfe206d25a6d4923ac7f1
Reviewed-on: https://code.wireshark.org/review/13622
Reviewed-by: Michal Labedzki <michal.labedzki@tieto.com>
Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Very weak form of heuristics has been added based on the FLAP id byte,
but disabled by default. Make it possible to use this protocol in the
RSA keys list dialog.
Bug: 11990
Change-Id: I61f24ae9679c738194393bed0d012d2a752171b2
Reviewed-on: https://code.wireshark.org/review/13195
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>
There is no padding in that case
Change-Id: Ib0ce37c4fea76435b4cedfbd7d3d72420e4860eb
Reviewed-on: https://code.wireshark.org/review/13618
Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
Change-Id: I2aa1a2d0e20cca6c979d51135e7fe9ea7a084847
Reviewed-on: https://code.wireshark.org/review/13609
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>
Change-Id: Ic23b26f87f38db0a40213ce7c954c8618dc966eb
Reviewed-on: https://code.wireshark.org/review/13610
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>
Fix decoding of sendRoutingInfoForSM (SRISM)
application contexts version 1 and version 2.
Use a (slightly modified) version of the ASN.1 from
ETS 300 599: December 2000 (GSM 09.02 version 4.19.1), clause 14.7.6
which has LocationInfoWithLMSI that is incompatible with
application context version 3 in
3GPP TS 29.002 version 3.20.0 Release 1999, clause 17.7.6.
Bug: 9622
Ping-Bug: 9704
Change-Id: Icc9a0a1743a6eb4c907f4cab3fb2137db139ad74
Reviewed-on: https://code.wireshark.org/review/13572
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
return the error to the caller, exit the loop and the dissection...
Change-Id: Iba64a5d5e4f79bc33c2b1c91b937c9726e15a802
Reviewed-on: https://code.wireshark.org/review/13587
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>