Have the Wiretap code just do a heuristic test to see if the file looks
like a RFC 7468 file and just had the entire blob of raw file data to
the caller, with an encapsulation type of WTAP_ENCAP_RFC7468.
Have a file-rfc7468.c dissector that processes the lines of the file,
displaying all of them. Have it extract the label from the
pre-encapsulation boundary line, and, after it's decoded the
base64-encoded data lines into a blob of data, try handing the tvbuff
with the blob to dissectors that have registered in the
"pem.preeb_label" dissector table with the appropriate label value, and
hand it to the raw BER dissector only if that fails.
This allows some files to have the content dissected as more than just a
raw blob of BER-encoded data.
Change-Id: I98db9f0beb86e5694fb8e886005a2df4fc96ba71
Reviewed-on: https://code.wireshark.org/review/28914
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Having these build tools in machine code poses problems when cross-compiling.
The most significant being that we need to find the host and build GLiB
dependencies at compile-time.
There is no noticeable speed difference between the Python and C implementation.
Ping-Bug: 14622
Change-Id: Id13f823c7f4abf51edfa291e703028873748989f
Reviewed-on: https://code.wireshark.org/review/28130
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
make-taps and make dissectors are build tools so that is the natural
location for them.
See also 99ec2b58eb68ab8530245dd13485612695ba064a and bug 14622.
Change-Id: I754848ea1c614bfa7121c44d89136ac3cba8a734
Reviewed-on: https://code.wireshark.org/review/27928
Petri-Dish: João Valverde <j@v6e.pt>
Tested-by: Petri Dish Buildbot
Reviewed-by: João Valverde <j@v6e.pt>
DoIP is a vehicle bus protocol. It is carried by TCP or UDP and may include an UDS payload.
Change-Id: I1459c51fd710da8e2aaff0056bbf3f6e42c1b25e
Reviewed-on: https://code.wireshark.org/review/27448
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
CMake 3.11 with the Ninja generator started complaining about CMP0058
related to ui/qt/CMakeFiles/qtui_autogen.dir/RCCstock_iconsInfo.cmake
amd other files (AUTORCC). While the policy could be set explicitly,
let's try to modernize the CMake configuration:
- Drop CMP0042, if this gives issues with macOS, then it must be solved
in a different way using non-deprecated methods.
- Drop CMP0054 and ensure that all if("${foo}") and if(${foo}) are
converted to if(foo).
- Remove string comparison against "-NOTFOUND", it already evaluates to
false in an if condition.
- Use CXX_STANDARD/CXX_STANDARD_REQUIRED for Qt 5.7 and newer.
- Assume that copy_if_different can accept multiple sources (CMake 3.5).
- Consistency: Out of the 60 CMake 3.11 FindXxx.cmake files that use
find_library, 34 contain "XXX_LIBRAR" while 16 contain "Xxx_LIBRAR".
Let's assume uppercase variables (now custom MaxMindDB include dirs
are correctly used).
CMake 3.5 was chosen as the next version because of its wide support.
Ubuntu 14.04 ships with cmake3 3.5.1, Debian jessie-backports has 3.6.2,
EPEL for CentOS/RHEL6 includes cmake3 3.6.1 and SLES12 SP2 has 3.5.
Change-Id: I2fa7b94bf8cc78411f414987d17bab3a33dfb360
Reviewed-on: https://code.wireshark.org/review/27444
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Dissector for the VESA DisplayPort AUX channel protocol.
Bug: 14651
Change-Id: I5c0c7668bda969086d9d6e5069aad87e929f6340
Reviewed-on: https://code.wireshark.org/review/27311
Reviewed-by: Dario Lombardo <lomato@gmail.com>
Petri-Dish: Dario Lombardo <lomato@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
When built with -DCMAKE_BUILD_WITH_INSTALL_RPATH=1, make-taps and
make-dissectors fail to run because they cannot locate libwsutil.so.0.
Since v2.9.0rc0-178-gbb81bef535 ("glib: Get rid of GLIB_CHECK_VERSION as
we now require 2.32.0") wsutil is definitely no longer needed.
Change-Id: Ida269fdb5f2cba979e3776f57c1a6bf3d546fe5d
Reviewed-on: https://code.wireshark.org/review/27329
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Dissector for GSM-R protocol. Specification ETSI TS 102 610.
Trace example in https://wiki.wireshark.org/SampleCaptures [[attachment:gsm-r.uus1.pcap]]
Change-Id: I7496bfa141d75b3460f7c3bdbb791e24d4810231
Reviewed-on: https://code.wireshark.org/review/26929
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
This adds support for the TPM 2.0 "protocol" as defined
by the Trusted Computing Group (TCG) specification.
The specification can be found here:
https://trustedcomputinggroup.org/tpm-library-specification/
The specification defines the format of the all TPM requests
and responses that this dissector supports.
A sample capture file that can be used for testing this
can be found in the https://wiki.wireshark.org/SampleCaptures
It is called policy-authorizeNV.pcap.
Change-Id: I557cb779f3adc5313e6d3498bbfeb56fdd308fbf
Reviewed-on: https://code.wireshark.org/review/26866
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The Osmocom GSUP protocol is a light-weight alternative to the
classic GSM MAP protocol. It operates between (MSC|SGSN) and HLR.
Change-Id: I954c7e332dce3a8855f7f4ace0b878f66da6f02e
Reviewed-on: https://code.wireshark.org/review/25477
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Tested with some hand-generated PDUs.
Change-Id: Ic603d0ca4578d23121e438ac2458be34e63492d2
Reviewed-on: https://code.wireshark.org/review/26755
Petri-Dish: Martin Mathieson <martin.r.mathieson@googlemail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Martin Mathieson <martin.r.mathieson@googlemail.com>
The RDMA reply chunk is used for a large RPC reply which does not fit
into a single SEND operation and does not have a single large opaque,
e.g., NFS READDIR. The RPC call packet is used only to set up the RDMA
reply chunk. The whole RPC reply is transferred via RDMA writes.
Fragments are added on any RDMA write packet, RDMA_WRITE_ONLY,
RDMA_WRITE_FIRST, etc., and the reassembly is done on the reply
message. The RPC reply packet has no data (RDMA_NOMSG) but
fragments are reassembled and the whole RPC reply is dissected.
The RDMA read chunk list is used for a large RPC call which has
at least one large opaque, e.g., NFS WRITE. The RPC call packet
is used only to set up the RDMA read chunk list. It also has the
reduced message data which includes the first fragment (XDR data
up to and including the opaque length), but it could also have
fragments between each read chunk and the last fragment after
the last read chunk data. The reduced message is then broken
down into fragments and inserted into the reassembly table.
Since the RDMA read chunk list is set up in the RPC call
then do not dissect the upper layer in this case and just
label rest of packet as "Data" since the reassembly will
be done on the last read response.
The protocol gives the XDR position where each chunk must be
inserted into the XDR stream thus as long as the maximum
I/O size is known it is possible to know exactly where to
insert these fragments. This maximum I/O size is set on the
first READ_RESPONSE_FIRST or READ_RESPONSE_MIDDLE but in case
where any of these packets have not been seen then a value
of 100 is used (real value should be at least 1024) but in
this case the message numbers are not consecutive between
chunks but since the total size of all chunks is verified to
make sure there is a complete message to reassemble then all
fragments should be in the correct order.
Fragments are added on any RDMA read packet: RDMA_READ_RESPONSE_ONLY,
RDMA_READ_RESPONSE_FIRST, etc., and the reassembly is done on the
last read response. Since there could be multiple chunks and each
chunk could have multiple segments then the total size must be
checked to complete the reassembly because in this case there
will be multiple READ_RESPONSE_LAST.
The RDMA write chunk list is used for a large RPC reply which has
at least one large opaque, e.g., NFS READ. The RPC call packet is
used only to set up the RDMA write chunk list. The opaque data is
then transferred via RDMA writes and then the RPC reply packet is
sent from the server.
The RPC reply packet has the reduced message data which includes
the first fragment (XDR data up to and including the opaque length),
but it could also have fragments between each write chunk and the
last fragment after the last write chunk data. The reduced message
is then broken down into fragments and inserted into the reassembly
table. Since the RPC reply is sent after all the RDMA writes then
the fragments from these writes must be inserted in the correct
order: the first RDMA write fragment is inserted with message
number 1, since the first fragment (message number 0) will come
from the very last packet (the RPC reply with RDMA_MSG). Also,
the last packet could have fragments which must be inserted in
between chunk data, therefore message numbers from one chunk to
another are not consecutive.
In contrast with the RDMA read chunk list, the protocol does not
allow an XDR position in the RDMA write chunks, since the RPC
client knows exactly where to insert the chunk's data because
of the virtual address of the DDP (direct data placement) item.
There is no way to map a virtual address with an XDR position,
thus in order to reassemble the XDR stream a two pass approach
is used. In the first pass (visited = 0), all RDMA writes are
inserted as fragments leaving a gap in between each chunk.
Then the dissector for the upper layer is called with a flag
letting the dissector know that it is dealing with a reduced
message so all DDP enabled operations handle the opaque data
as having only the size of the opaque but not the data and
reporting back the offset from the end of the message.
Once the upper layer dissector returns, this layer now has a
list of DDP eligible item's offsets which are then translated
into XDR offsets and then the RPC reply packet is broken into
fragments and inserted in the right places as in the case for
the RDMA read chunk list. On the second pass (visited = 1),
all fragments have already been inserted into the reassembly
table so it just needs to reassembled the whole message and
then call the upper layer dissector.
RFC 8267 specifies the upper layer bindings to RPC-over-RDMA
version 1 for NFS. Since RPC-over-RDMA version 1 specifies the
XDR position for the read chunks then only the write chunk DDP
eligible items are handled in the upper layer, in this case the
NFS layer. These are the only procedures or operations eligible
for write chunks:
* The opaque data result in the NFS READ procedure or operation
* The pathname or linkdata result in the NFS READLINK procedure
or operation
Two functions are defined to signal and report back the DDP
eligible item's offset to be used by the upper layers.
Function rpcrdma_is_reduced() is used to signal the upper layer
that it is dealing with a reduced data message and thus should
ignore DDP eligible item's opaque processing and just report
back the offset where the opaque data should be. This reporting
is done using the second function rpcrdma_insert_offset().
Reassembly is done for InfiniBand only. Reassemble fragments using
the packet sequence number (PSN) of each RDMA I/O fragment to make
sure the message is reassembled correctly when fragments are sent
out of order. Also a unique message id is used for each message so
fragments are reassembled correctly when fragments of different
messages are sent in parallel.
The reassembled message could be composed of multiple chunks
and each chunk in turn could be composed of multiple segments
in which each segment could be composed of multiple requests
and of course each request is composed of one or more fragments.
Thus in order to have all fragments for each segment belonging
to the same message, a list of segments is created and all
segments belonging to the same message are initialized with
the same message id. These segments are initialized and added
to the list on the call side on RDMA_MSG by calling
process_rdma_lists.
Bug: 13260
Change-Id: Icf57d7c46c3ba1de5d019265eb151a81d6019dfd
Reviewed-on: https://code.wireshark.org/review/24613
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
This change introduces the OSCORE dissector, following
draft-ietf-core-object-security-07. It performs decryption and
authenticity
check on requests.
Bug: 14417
Change-Id: I92e45d66d5df51f6d4dbea4ef44e707955b65bee
Reviewed-on: https://code.wireshark.org/review/25480
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Change-Id: I34f610a19a972db1c08d7896453e5ed671ec4dc6
Reviewed-on: https://code.wireshark.org/review/26394
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
This is not a complete dissector but can be commited as is. To be worked
on.
Change-Id: I2e698b57c849013657a1eeacef4b984c8b8c39ee
Reviewed-on: https://code.wireshark.org/review/26051
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
This adds a dissector for the Steam In-Home Streaming
Discovery Protocol by Valve Software.
Useful documentation can be found at:
https://codingrange.com/blog/steam-in-home-streaming-discovery-protocol
Change-Id: I26a79e201cfb0aad0ca702ac962e1e7b1b541517
Reviewed-on: https://code.wireshark.org/review/23615
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
All changes to the set of Wireshark source files must be done in both
Makefile.am and CMakeLists.txt files.
Change-Id: Iad0db912dcfd149d0f5acbb38489e0a34c6dac89
Reviewed-on: https://code.wireshark.org/review/25778
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Stuff that calls it is built in, and stuff it calls is built in, so
there's not much point in having it be a plugin; we already have
examples of plugin dissectors.
Change-Id: I512e0fda62faedb5f03f476fbece2e267e1d644f
Reviewed-on: https://code.wireshark.org/review/25775
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Adding Session Multiplex Protocol SMP
SMP is used by TDS when MARS in enabled.
Bug: 14110
Change-Id: Ia4113c627d107da6c3d51e4004265efb228a297b
Reviewed-on: https://code.wireshark.org/review/25509
Reviewed-by: Craig Jackson <cejackson51@gmail.com>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
Change-Id: I306341c7cddf8facb4a9ca62254a465a1da22174
Reviewed-on: https://code.wireshark.org/review/25423
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
Change-Id: I049c8b9b9a0a1da2243217532186ba5a19cf5671
Signed-off-by: Jaap Keuter <jaap.keuter@xs4all.nl>
Reviewed-on: https://code.wireshark.org/review/25424
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
Have the make-dissectors CMake target explicitly depend on copy_cli_dlls,
otherwise we might try to create dissectors.c before libglib-2.0-0.dll
has been copied into place. It looks like this is what's been causing
our random Windows PD failures.
Change-Id: Ia2445f17abd2c73113ab269ba6c606f48e724d93
Reviewed-on: https://code.wireshark.org/review/25292
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Gerald Combs <gerald@wireshark.org>
ASN.1 prose imported from the specification and heavily modified
manually to workaround its poor quality.
Some of them are marked with -- WS modification comment, some are not.
Probably useless as-is, but it is an initial start until an updated
version is available.
Change-Id: I19ab6cedb6aa23c8ed57bae525ee4a3391494e32
Reviewed-on: https://code.wireshark.org/review/25235
Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
This interperates the main body of Lustre traffic.
This dissects all current Lustre OPCODES (as of Lustre 2.10.2)
This dissects MDS REINT sub-opcodes
This dissects LDLM Intent opcodes
This dissects LLOG EADATA
Conversation matching is just IP based and not IP/port based.
Only one lustre "instance" can be running on a given host at a given time,
and request / reply pairs aren't don't always match by port numbers.
Add exception for lustre_* structure names in PROTOABBREV.
We have several lustre.lustre_* because the internal lustre structre is
named lustre_ (i.e. lustre_handle or lustre_msg_v2)
This is still a work in progress, as there are missing FLAG values
and some LLOG EADATA structures that aren't fully decoded.
Change-Id: If57085e2692565336e49f40fb475ca1035da7a35
Signed-off-by: Nathaniel Clark <nathaniel.l.clark@intel.com>
Reviewed-on: https://code.wireshark.org/review/24800
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: I360bc4f802e28e9fc64cbd5cc06e514cbaf3b25f
Reviewed-on: https://code.wireshark.org/review/25091
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Guy Harris
Harald Welte