Add a decode-as dissector table, and use its entry to dissect the
payload of an CLNP (or ES-IS) security option.
This allows the user to specify that it should be dissected as used in
ICAO's ATN specification without requiring so much entanglement between
the CLNP dissector, the OSI options dissector, and the code to dissect
the ATN security option.
(It would also allw other OSI profiles to provide their own such
dissector, e.g. GOSIP if anybody still cares, or TUBA in case it was
ever even used on a network.)
- Dissect every message as an unknown sentence. Each sentence field is dissected to generic item displaying the value
- Most talker id and sentence id will be converted to readable description
- Checksum is verified
Pass the sysdig.param.asyncevent.data start and offset to the Falco Bridge
dissector, and use that to highlight the evt.buffer and fd fields.
Pass the data to the ELF dissector if we find an ELF magic ID.
This commit implemements PLDM dissector
for the base specification of the protocol
which is done following DMTF guideline
documentation -
https://www.dmtf.org/sites/default/files/standards/documents/DSP0240_1.1.0.pdf
Testing : For verification of dissector
pcap file collected during host poweron
is used.
Signed-off-by: Riya Dixit <riyadixitagra@gmail.com>
* Replaced all usages of rf4ce_yes_no_vals by tfs_yes_no
* Replaced all usages of rf4ce_en_dis_vals by tfs_enabled_disabled
* Removed packet-rf4ce-common.c and packet-rf4ce-common.h
The `frame` dissector has a case statement for dealing with PcapNG
[custom blocks][1], and has some hard-coding in for specific types of
custom block, currently TCP Black Box Log (bblog) and pcaplog blocks.
Propose replacing case statement with a new sub-dissector table keyed on
the Private Enterprise Number, tentatively named `pcapng_custom_block`.
Factor out bblog code from `packet-frame.c` into `packet-bblog.c`. Have
it register itself with this new table.
Create `packet-pcaplog.c` and factor out pcaplog code to that file. Have
it register itself with this new table.
This is one possible way of addressing the concern discussed in !3990 of
generalizing the handling of custom blocks. The hope is to reduce the
tightness of coupling `packet-frame.c` with every new custom block we
want to support.
There remains, unfortunately, tight coupling with custom block
*[options][2]* that exist on standard PcapNG blocks, since the current
established precedent is to give fields for supported options a `frame.`
prefix and put them in the Frame protocol tree. This proposal treats
that as out of scope.
There is also bblog-specific code in `wiretap/pcapng.c`. It may be
possible to move that into `packet-bblog.c`. This is also beyond the
scope of this proposal.
[1]: https://www.ietf.org/archive/id/draft-tuexen-opsawg-pcapng-05.html#name-custom-block
[2]: https://www.ietf.org/archive/id/draft-tuexen-opsawg-pcapng-05.html#name-custom-options
This change adds a dissector for the X.75 protocol,
commonly used on ISDN B-channels.
The protocol is defined in ITU-T Rec. X.75 (10/96).
X.75 is similar to LAPB, but has no further protocols on top
of the asychronous link layer.
iPerf3 is quite different from iPerf2 and so requires its own dissector.
Recognizes "control connection" messages (session cookies, connection
request refusal, etc) and data (labeled with its length, UDP messages
have their sequence number parsed)
It registers with TCP and UDP port 5201, which is unused by any other
dissector in Wireshark.
Add a dissector for the 802.1cb protocol R-TAGs. This displays the R-TAG
and continues with the contained sub-protocol. The dissector does not do
de-duplication, or even check for dropped packets.
The MDB (Multi-Drop Bus) protocol is used inside a vending machine. MDB
defines the communication between the main control board (VMC = Vending
Machine Controller) and peripheral components, e.g. a payment terminal
or a bill validator.
The protocol specification is available from
https://namanow.org/nama-releases-mdb-version-4-3/
The pcap input format for this dissector is documented at
https://www.kaiser.cx/pcap-mdb.html
We are in the process of requesting an official DLT for MDB.
For now, the dissector can be mapped to a User-DLT for testing.
Initial work on supporting VP9
update release-notes.adoc
add vp9 to new protocol support section
fix warnings
replace 0xFF by 0 for bits mask
Fix warnings
Rename pid to pid_ext
Rename pg to pg_ext
The dissector supports data, control, status, and vendor defined
messages. As well as the following technologies:
- CAN
- CAN-FD
- LIN
- FlexRay
- Analog
- UART
- Ethernet
Features:
- Supports also compressed and TLS-encrypted Zabbix connections as well
as TCP desegmenting
- Dissects both passive agent connections (10050/tcp, plaintext-based)
and active agent, proxy and sender/trapper connections (10051/tcp,
JSON-based), ports are configurable
- Detects passive agent conversations by checking the request being
non-JSON (not depending on the well-known TCP ports)
- Calculates response times using protocol data saved in conversations
- Detects the connection type (proxy, agent, sender/trapper) and shows
tree and Info column information accordingly
- Dissects protocols up to Zabbix version 6.4 (currently latest) and
7.0 (currently in alpha)
- Does not support passive agent connections in Zabbix 3.x or earlier
(it does not have the normal Zabbix header; note that Zabbix 4.0 was
released in 2018)
Use FindPython3.cmake instead of the deprecated FindPythonInterp.cmake,
to make sure we actually find Python3.
Don't use the module with MSYS2 because it is buggy and exhibits broken
behaviour.
Run it earlier in the configuration, just as a precaution, so other
indirect calls to find python don't happen earlier.
This reverts commit d6380e7ae4.
Turns out we were unwittingly still using FindPythonInterp
instead of FindPython3.cmake, via LocatePythonModule.cmake,
nd this commit actually enabled FindPython3.cmake. Also turns
out FindPython3.cmake is far too clever and very buggy with MSYS2.
It will usually not find the correct python binary and fail in many
suprising ways, depending on which combination of Python Windows
installations is present.
Guy Harris
Manawyrm