2021-11-30 03:41:45 +00:00
|
|
|
/** @file
|
|
|
|
|
*
|
2021-08-20 09:17:14 +00:00
|
|
|
* Definitions for exported_pdu TLVs
|
|
|
|
|
* Copyright 2013, Anders Broman <anders-broman@ericsson.com>
|
|
|
|
|
*
|
|
|
|
|
* Wireshark - Network traffic analyzer
|
|
|
|
|
* By Gerald Combs <gerald@wireshark.org>
|
|
|
|
|
* Copyright 1998 Gerald Combs
|
|
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef EXPORTED_PDU_TLVS_H
|
|
|
|
|
#define EXPORTED_PDU_TLVS_H
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* This is the format of the link-layer header of packets of type
|
|
|
|
|
* LINKTYPE_WIRESHARK_UPPER_PDU in pcap and pcapng files.
|
|
|
|
|
*
|
|
|
|
|
* It is a sequence of TLVs; at least one TLV MUST indicate what protocol is
|
|
|
|
|
* in the PDU following the TLVs.
|
|
|
|
|
*
|
2021-08-21 09:31:07 +00:00
|
|
|
* Each TLV contains, in order:
|
2021-08-20 09:17:14 +00:00
|
|
|
*
|
2021-08-21 09:31:07 +00:00
|
|
|
* a 2-byte big-endian type field;
|
|
|
|
|
* a 2-byte big-endian length field;
|
|
|
|
|
* a value, the length of which is indicated by the value of
|
|
|
|
|
* the length field (that value does not include the length
|
|
|
|
|
* of the type or length fields themselves).
|
2021-08-20 09:17:14 +00:00
|
|
|
*
|
2021-08-21 09:31:07 +00:00
|
|
|
* TLVs are not guaranteed to be aligned to any particular number
|
|
|
|
|
* of bytes.
|
2021-08-20 09:17:14 +00:00
|
|
|
*
|
2021-08-21 09:31:07 +00:00
|
|
|
* The list of TLVs may begin with a TLV of type EXP_PDU_TAG_OPTIONS_LENGTH;
|
|
|
|
|
* its value is a 4-byte integer value, giving the length of all TLVs
|
|
|
|
|
* following that TLV (i.e., the length does not include the length of
|
|
|
|
|
* the EXP_PDU_TAG_OPTIONS_LENGTH TLV). This tag is deprecated; it is
|
|
|
|
|
* not guaranteed to be present, and code reading packets should not
|
|
|
|
|
* require it to be present.
|
2021-08-20 09:17:14 +00:00
|
|
|
*
|
|
|
|
|
* The last TLV is of type EXP_PDU_TAG_END_OF_OPT; it has a length
|
|
|
|
|
* of 0, and the value is zero-length.
|
|
|
|
|
*
|
2021-08-21 09:31:07 +00:00
|
|
|
* For string values, a string may have zero, one, or more null bytes
|
|
|
|
|
* at the end; code that reads the string value must not assume that
|
|
|
|
|
* there are, or are not, null bytes at the end. Null bytes are included
|
|
|
|
|
* in the length field, but are not part of the string value.
|
2021-08-20 09:17:14 +00:00
|
|
|
*
|
2021-08-21 09:31:07 +00:00
|
|
|
* For integral values, the values are in big-endian format.
|
2021-08-20 09:17:14 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* Tag values
|
|
|
|
|
*
|
|
|
|
|
* Do NOT add new values to this list without asking
|
|
|
|
|
* wireshark-dev[AT]wireshark.org for a value. Otherwise, you run the risk of
|
|
|
|
|
* using a value that's already being used for some other purpose, and of
|
|
|
|
|
* having tools that read exported_pdu captures not being able to handle
|
|
|
|
|
* captures with your new tag value, with no hope that they will ever be
|
|
|
|
|
* changed to do so (as that would destroy their ability to read captures
|
|
|
|
|
* using that value for that other purpose).
|
|
|
|
|
*/
|
Dissector names are not protocol names.
A given protocol's packet format may depend, for example, on which
lower-level protocol is transporting the protocol in question. For
example, protocols that run atop both byte-stream protocols such as TCP
and TLS, and packet-oriented protocols such as UDP or DTLS, might begin
the packet with a length when running atop a byte-stream protocol, to
indicate where this packet ends and the next packet begins in the byte
stream, but not do so when running atop a packet-oriented protocol.
Dissectors can handle this in various ways:
For example, the dissector could attempt to determine the protocol over
which the packet was transported.
Unfortunately, many of those mechanisms do so by fetching data from the
packet_info structure, and many items in that structure act as global
variables, so that, for example, if there are two two PDUs for protocol
A inside a TCP segment, and the first protocol for PDU A contains a PDU
for protocol B, and protocol B's dissector, or a dissector it calls,
modifies the information in the packet_info structure so that it no
longer indicates that the parent protocol is TCP, the second PDU for
protocol A might not be correctly dissected.
Another such mechanism is to query the previous element in the layers
structure of the packet_info structure, which is a list of protocol IDs.
Unfortunately, that is not a list of earlier protocols in the protocol
stack, it's a list of earlier protocols in the dissection, which means
that, in the above example, when the second PDU for protocol A is
dissected, the list is {...,TCP,A,B,...,A}, which means that the
previous element in the list is not TCP, so, again, the second PDU for
protocol A will not be correctly dissected.
An alternative is to have multiple dissectors for the same protocol,
with the part of the protocol that's independent of the protocol
transporting the PDU being dissected by common code. Protocol B might
have an "over a byte-stream transport" dissector and an "over a packet
transport" dissector, with the first dissector being registered for use
over TCP and TLS and the other dissector being registered for use over
packet protocols. This mechanism, unlike the other mechanisms, is not
dependent on information in the packet_info structure that might be
affected by dissectors other than the one for the protocol that
transports protocol B.
Furthermore, in a LINKTYPE_WIRESHARK_UPPER_PDU pcap or pcapng packet for
protocol B, there might not be any information to indicate the protocol
that transports protocol B, so there would have to be separate
dissectors for protocol B, with separate names, so that a tag giving the
protocol name would differ for B-over-byte-stream and B-over-packets.
So:
We rename EXP_PDU_TAG_PROTO_NAME and EXP_PDU_TAG_HEUR_PROTO_NAME to
EXP_PDU_TAG_DISSECTOR_NAME and EXP_PDU_TAG_HEUR_DISSECTOR_NAME, to
emphasize that they are *not* protocol names, they are dissector names
(which has always been the case - if there's a protocol with that name,
but no dissector with that name, Wireshark will not be able to handle
the packet, as it will try to look up a dissector given that name and
fail).
We fix that exported PDU dissector to refer to those tags as dissector
names, not protocol names.
We update documentation to refer to them as DISSECTOR_NAME tags, not
PROTO_NAME tags. (If there is any documentation for this outside the
Wireshark source, it should be updated as well.)
We add comments for calls to dissector_handle_get_dissector_name() where
the dissector name is shown to the user, to indicate that it might be
that the protocol name should be used.
We update the TLS and DTLS dissectors to show the encapsulated protocol
as the string returned by dissector_handle_get_long_name(); as the
default is "Application Data", it appeaers that a descriptive name,
rather than a short API name, should be used. (We continue to use the
dissector name in debugging messages, to indicate which dissector was
called.)
2022-09-11 05:37:11 +00:00
|
|
|
#define EXP_PDU_TAG_END_OF_OPT 0 /**< End-of-options Tag. */
|
2021-08-20 09:17:14 +00:00
|
|
|
/* 1 - 9 reserved */
|
Dissector names are not protocol names.
A given protocol's packet format may depend, for example, on which
lower-level protocol is transporting the protocol in question. For
example, protocols that run atop both byte-stream protocols such as TCP
and TLS, and packet-oriented protocols such as UDP or DTLS, might begin
the packet with a length when running atop a byte-stream protocol, to
indicate where this packet ends and the next packet begins in the byte
stream, but not do so when running atop a packet-oriented protocol.
Dissectors can handle this in various ways:
For example, the dissector could attempt to determine the protocol over
which the packet was transported.
Unfortunately, many of those mechanisms do so by fetching data from the
packet_info structure, and many items in that structure act as global
variables, so that, for example, if there are two two PDUs for protocol
A inside a TCP segment, and the first protocol for PDU A contains a PDU
for protocol B, and protocol B's dissector, or a dissector it calls,
modifies the information in the packet_info structure so that it no
longer indicates that the parent protocol is TCP, the second PDU for
protocol A might not be correctly dissected.
Another such mechanism is to query the previous element in the layers
structure of the packet_info structure, which is a list of protocol IDs.
Unfortunately, that is not a list of earlier protocols in the protocol
stack, it's a list of earlier protocols in the dissection, which means
that, in the above example, when the second PDU for protocol A is
dissected, the list is {...,TCP,A,B,...,A}, which means that the
previous element in the list is not TCP, so, again, the second PDU for
protocol A will not be correctly dissected.
An alternative is to have multiple dissectors for the same protocol,
with the part of the protocol that's independent of the protocol
transporting the PDU being dissected by common code. Protocol B might
have an "over a byte-stream transport" dissector and an "over a packet
transport" dissector, with the first dissector being registered for use
over TCP and TLS and the other dissector being registered for use over
packet protocols. This mechanism, unlike the other mechanisms, is not
dependent on information in the packet_info structure that might be
affected by dissectors other than the one for the protocol that
transports protocol B.
Furthermore, in a LINKTYPE_WIRESHARK_UPPER_PDU pcap or pcapng packet for
protocol B, there might not be any information to indicate the protocol
that transports protocol B, so there would have to be separate
dissectors for protocol B, with separate names, so that a tag giving the
protocol name would differ for B-over-byte-stream and B-over-packets.
So:
We rename EXP_PDU_TAG_PROTO_NAME and EXP_PDU_TAG_HEUR_PROTO_NAME to
EXP_PDU_TAG_DISSECTOR_NAME and EXP_PDU_TAG_HEUR_DISSECTOR_NAME, to
emphasize that they are *not* protocol names, they are dissector names
(which has always been the case - if there's a protocol with that name,
but no dissector with that name, Wireshark will not be able to handle
the packet, as it will try to look up a dissector given that name and
fail).
We fix that exported PDU dissector to refer to those tags as dissector
names, not protocol names.
We update documentation to refer to them as DISSECTOR_NAME tags, not
PROTO_NAME tags. (If there is any documentation for this outside the
Wireshark source, it should be updated as well.)
We add comments for calls to dissector_handle_get_dissector_name() where
the dissector name is shown to the user, to indicate that it might be
that the protocol name should be used.
We update the TLS and DTLS dissectors to show the encapsulated protocol
as the string returned by dissector_handle_get_long_name(); as the
default is "Application Data", it appeaers that a descriptive name,
rather than a short API name, should be used. (We continue to use the
dissector name in debugging messages, to indicate which dissector was
called.)
2022-09-11 05:37:11 +00:00
|
|
|
#define EXP_PDU_TAG_OPTIONS_LENGTH 10 /**< Total length of the options excluding this TLV
|
|
|
|
|
* Deprecated - do not use
|
|
|
|
|
*/
|
|
|
|
|
#define EXP_PDU_TAG_LINKTYPE 11 /**< Deprecated - do not use */
|
|
|
|
|
#define EXP_PDU_TAG_DISSECTOR_NAME 12 /**< The value part should be an ASCII non NULL terminated string
|
|
|
|
|
* of the registered dissector used by Wireshark e.g "sip"
|
|
|
|
|
* Will be used to call the next dissector.
|
|
|
|
|
* NOTE: this is NOT a protocol name;
|
|
|
|
|
* a given protocol may have multiple
|
|
|
|
|
* dissectors, if, for example, the
|
|
|
|
|
* protocol headers depend on the
|
|
|
|
|
* protocol being used to transport
|
|
|
|
|
* the protocol in question.
|
|
|
|
|
*/
|
|
|
|
|
#define EXP_PDU_TAG_HEUR_DISSECTOR_NAME 13 /**< The value part should be an ASCII non NULL terminated string
|
|
|
|
|
* containing the heuristic dissector unique short name given
|
2021-08-20 09:17:14 +00:00
|
|
|
* during registration, e.g "sip_udp"
|
|
|
|
|
* Will be used to call the next dissector.
|
|
|
|
|
*/
|
|
|
|
|
#define EXP_PDU_TAG_DISSECTOR_TABLE_NAME 14 /**< The value part should be an ASCII non NULL terminated string
|
|
|
|
|
* containing the dissector table name given
|
|
|
|
|
* during registration, e.g "gsm_map.v3.arg.opcode"
|
|
|
|
|
* Will be used to call the next dissector.
|
|
|
|
|
*/
|
|
|
|
|
|
Dissector names are not protocol names.
A given protocol's packet format may depend, for example, on which
lower-level protocol is transporting the protocol in question. For
example, protocols that run atop both byte-stream protocols such as TCP
and TLS, and packet-oriented protocols such as UDP or DTLS, might begin
the packet with a length when running atop a byte-stream protocol, to
indicate where this packet ends and the next packet begins in the byte
stream, but not do so when running atop a packet-oriented protocol.
Dissectors can handle this in various ways:
For example, the dissector could attempt to determine the protocol over
which the packet was transported.
Unfortunately, many of those mechanisms do so by fetching data from the
packet_info structure, and many items in that structure act as global
variables, so that, for example, if there are two two PDUs for protocol
A inside a TCP segment, and the first protocol for PDU A contains a PDU
for protocol B, and protocol B's dissector, or a dissector it calls,
modifies the information in the packet_info structure so that it no
longer indicates that the parent protocol is TCP, the second PDU for
protocol A might not be correctly dissected.
Another such mechanism is to query the previous element in the layers
structure of the packet_info structure, which is a list of protocol IDs.
Unfortunately, that is not a list of earlier protocols in the protocol
stack, it's a list of earlier protocols in the dissection, which means
that, in the above example, when the second PDU for protocol A is
dissected, the list is {...,TCP,A,B,...,A}, which means that the
previous element in the list is not TCP, so, again, the second PDU for
protocol A will not be correctly dissected.
An alternative is to have multiple dissectors for the same protocol,
with the part of the protocol that's independent of the protocol
transporting the PDU being dissected by common code. Protocol B might
have an "over a byte-stream transport" dissector and an "over a packet
transport" dissector, with the first dissector being registered for use
over TCP and TLS and the other dissector being registered for use over
packet protocols. This mechanism, unlike the other mechanisms, is not
dependent on information in the packet_info structure that might be
affected by dissectors other than the one for the protocol that
transports protocol B.
Furthermore, in a LINKTYPE_WIRESHARK_UPPER_PDU pcap or pcapng packet for
protocol B, there might not be any information to indicate the protocol
that transports protocol B, so there would have to be separate
dissectors for protocol B, with separate names, so that a tag giving the
protocol name would differ for B-over-byte-stream and B-over-packets.
So:
We rename EXP_PDU_TAG_PROTO_NAME and EXP_PDU_TAG_HEUR_PROTO_NAME to
EXP_PDU_TAG_DISSECTOR_NAME and EXP_PDU_TAG_HEUR_DISSECTOR_NAME, to
emphasize that they are *not* protocol names, they are dissector names
(which has always been the case - if there's a protocol with that name,
but no dissector with that name, Wireshark will not be able to handle
the packet, as it will try to look up a dissector given that name and
fail).
We fix that exported PDU dissector to refer to those tags as dissector
names, not protocol names.
We update documentation to refer to them as DISSECTOR_NAME tags, not
PROTO_NAME tags. (If there is any documentation for this outside the
Wireshark source, it should be updated as well.)
We add comments for calls to dissector_handle_get_dissector_name() where
the dissector name is shown to the user, to indicate that it might be
that the protocol name should be used.
We update the TLS and DTLS dissectors to show the encapsulated protocol
as the string returned by dissector_handle_get_long_name(); as the
default is "Application Data", it appeaers that a descriptive name,
rather than a short API name, should be used. (We continue to use the
dissector name in debugging messages, to indicate which dissector was
called.)
2022-09-11 05:37:11 +00:00
|
|
|
/* For backwards source compatibility */
|
|
|
|
|
#define EXP_PDU_TAG_PROTO_NAME EXP_PDU_TAG_DISSECTOR_NAME
|
|
|
|
|
#define EXP_PDU_TAG_HEUR_PROTO_NAME EXP_PDU_TAG_HEUR_DISSECTOR_NAME
|
|
|
|
|
|
2021-08-20 09:17:14 +00:00
|
|
|
/* Add protocol type related tags here.
|
|
|
|
|
* NOTE Only one protocol type tag may be present in a packet, the first one
|
|
|
|
|
* found will be used*/
|
|
|
|
|
/* 13 - 19 reserved */
|
|
|
|
|
#define EXP_PDU_TAG_IPV4_SRC 20 /**< IPv4 source address - 4 bytes */
|
|
|
|
|
#define EXP_PDU_TAG_IPV4_DST 21 /**< IPv4 destination address - 4 bytes */
|
|
|
|
|
#define EXP_PDU_TAG_IPV6_SRC 22 /**< IPv6 source address - 16 bytes */
|
|
|
|
|
#define EXP_PDU_TAG_IPV6_DST 23 /**< IPv6 destination address - 16 bytes */
|
|
|
|
|
|
|
|
|
|
/* Port type values for EXP_PDU_TAG_PORT_TYPE; these do not necessarily
|
|
|
|
|
* correspond to port type values inside libwireshark. */
|
|
|
|
|
#define EXP_PDU_PT_NONE 0
|
|
|
|
|
#define EXP_PDU_PT_SCTP 1
|
|
|
|
|
#define EXP_PDU_PT_TCP 2
|
|
|
|
|
#define EXP_PDU_PT_UDP 3
|
|
|
|
|
#define EXP_PDU_PT_DCCP 4
|
|
|
|
|
#define EXP_PDU_PT_IPX 5
|
|
|
|
|
#define EXP_PDU_PT_NCP 6
|
|
|
|
|
#define EXP_PDU_PT_EXCHG 7
|
|
|
|
|
#define EXP_PDU_PT_DDP 8
|
|
|
|
|
#define EXP_PDU_PT_SBCCS 9
|
|
|
|
|
#define EXP_PDU_PT_IDP 10
|
|
|
|
|
#define EXP_PDU_PT_TIPC 11
|
|
|
|
|
#define EXP_PDU_PT_USB 12
|
|
|
|
|
#define EXP_PDU_PT_I2C 13
|
|
|
|
|
#define EXP_PDU_PT_IBQP 14
|
|
|
|
|
#define EXP_PDU_PT_BLUETOOTH 15
|
|
|
|
|
#define EXP_PDU_PT_TDMOP 16
|
2021-08-25 20:15:39 +00:00
|
|
|
#define EXP_PDU_PT_IWARP_MPA 17
|
2021-10-28 01:01:06 +00:00
|
|
|
#define EXP_PDU_PT_MCTP 18
|
2021-08-20 09:17:14 +00:00
|
|
|
|
|
|
|
|
#define EXP_PDU_TAG_PORT_TYPE 24 /**< part type - 4 bytes, EXP_PDU_PT value */
|
|
|
|
|
#define EXP_PDU_TAG_SRC_PORT 25 /**< source port - 4 bytes (even for protocols with 2-byte ports) */
|
|
|
|
|
#define EXP_PDU_TAG_DST_PORT 26 /**< destination port - 4 bytes (even for protocols with 2-byte ports) */
|
|
|
|
|
|
|
|
|
|
#define EXP_PDU_TAG_SS7_OPC 28
|
|
|
|
|
#define EXP_PDU_TAG_SS7_DPC 29
|
|
|
|
|
|
|
|
|
|
#define EXP_PDU_TAG_ORIG_FNO 30
|
|
|
|
|
|
|
|
|
|
#define EXP_PDU_TAG_DVBCI_EVT 31
|
|
|
|
|
|
|
|
|
|
#define EXP_PDU_TAG_DISSECTOR_TABLE_NAME_NUM_VAL 32 /**< value part is the numeric value to be used calling the dissector table
|
|
|
|
|
* given with tag EXP_PDU_TAG_DISSECTOR_TABLE_NAME, must follow immediately after the table tag.
|
|
|
|
|
*/
|
|
|
|
|
|
2021-08-21 09:31:07 +00:00
|
|
|
#define EXP_PDU_TAG_COL_PROT_TEXT 33 /**< UTF-8 text string to put in COL_PROTOCOL, one use case is in conjunction with dissector tables where
|
2021-08-20 09:17:14 +00:00
|
|
|
* COL_PROTOCOL might not be filled in.
|
|
|
|
|
*/
|
|
|
|
|
|
2021-08-25 20:15:39 +00:00
|
|
|
|
2021-08-21 09:31:07 +00:00
|
|
|
/**< value part is structure passed into TCP subdissectors. The field
|
|
|
|
|
begins with a 2-byte version number; if the version number value is
|
|
|
|
|
1, the value part is in the form:
|
|
|
|
|
|
2021-08-20 09:17:14 +00:00
|
|
|
version 2 bytes - xport PDU version of structure (for backwards/forwards compatibility)
|
|
|
|
|
seq 4 bytes - Sequence number of first byte in the data
|
|
|
|
|
nxtseq 4 bytes - Sequence number of first byte after data
|
|
|
|
|
lastackseq 4 bytes - Sequence number of last ack
|
|
|
|
|
is_reassembled 1 byte - Non-zero if this is reassembled data
|
|
|
|
|
flags 2 bytes - TCP flags
|
|
|
|
|
urgent_pointer 2 bytes - Urgent pointer value for the current packet
|
|
|
|
|
|
|
|
|
|
All multi-byte values are in big-endian format. There is no alignment
|
|
|
|
|
padding between values, so seq. nxtseq, and lastackseq are not aligned
|
|
|
|
|
on 4-byte boundaries, andflags and urgent_pointer are not aligned on
|
|
|
|
|
2-byte boundaries.
|
|
|
|
|
*/
|
|
|
|
|
#define EXP_PDU_TAG_TCP_INFO_DATA 34
|
|
|
|
|
|
|
|
|
|
#define EXP_PDU_TAG_P2P_DIRECTION 35 /**< The packet direction (P2P_DIR_SENT, P2P_DIR_RECV). */
|
|
|
|
|
|
|
|
|
|
#define EXP_PDU_TAG_IPV4_LEN 4
|
|
|
|
|
#define EXP_PDU_TAG_IPV6_LEN 16
|
|
|
|
|
|
|
|
|
|
#define EXP_PDU_TAG_PORT_TYPE_LEN 4
|
|
|
|
|
#define EXP_PDU_TAG_PORT_LEN 4
|
|
|
|
|
|
|
|
|
|
#define EXP_PDU_TAG_SS7_OPC_LEN 8 /* 4 bytes PC, 2 bytes standard type, 1 byte NI, 1 byte padding */
|
|
|
|
|
#define EXP_PDU_TAG_SS7_DPC_LEN 8 /* 4 bytes PC, 2 bytes standard type, 1 byte NI, 1 byte padding */
|
|
|
|
|
|
|
|
|
|
#define EXP_PDU_TAG_ORIG_FNO_LEN 4
|
|
|
|
|
|
|
|
|
|
#define EXP_PDU_TAG_DVBCI_EVT_LEN 1
|
|
|
|
|
|
|
|
|
|
#define EXP_PDU_TAG_DISSECTOR_TABLE_NUM_VAL_LEN 4
|
|
|
|
|
|
|
|
|
|
#endif /* EXPORTED_PDU_TLVS_H */
|