OPC UA PubSub Sniffing concepts: Difference between revisions
Line 56: | Line 56: | ||
Some transports may not provide exactly the transport message received, but may transform it in some way. In such case, the OPC UA PubSub sniffer will not "see" the very original message as received, but will only be provided and see the transformed message data. This can happen, for example, if the transport provides and option to decompress the data. | Some transports may not provide exactly the transport message received, but may transform it in some way. In such case, the OPC UA PubSub sniffer will not "see" the very original message as received, but will only be provided and see the transformed message data. This can happen, for example, if the transport provides and option to decompress the data. | ||
Specifically: QuickOPC has an option to detect and auto-decompress data received in GZip format. This option is turned on by default in the MQTT transport, and turned off in the other transports (UDP, Ethernet). This means that when use use MQTT, and a GZip-ped message appears on the input, its capture data will already be decompressed in the {{Style=Identifier|TransportMessage}} capture. The fact that the data has been decompressed is indicated by the fact that the {{Style=Identifier|Compressed}} flag (property) is set in the | Specifically: QuickOPC has an option to detect and auto-decompress data received in GZip format. This option is turned on by default in the MQTT transport, and turned off in the other transports (UDP, Ethernet). This means that when use use MQTT, and a GZip-ped message appears on the input, its capture data will already be decompressed in the {{Style=Identifier|TransportMessage}} capture. The fact that the data has been decompressed is indicated by the fact that the {{Style=Identifier|Compressed}} flag (property) is set in the [[#Capture header|Capture header]]. | ||
= See also = | = See also = | ||
[[Using OpcCmd Utility as OPC UA PubSub Sniffer]] | [[Using OpcCmd Utility as OPC UA PubSub Sniffer]] |
Revision as of 08:57, 14 August 2022
Introduction
(TBD)
Capture types
(TBD)
Individual capture types
(TBD)
If the transport message cannot be parsed as an OPC UA PubSub message, the TransportMessage is the only capture emitted for the message. Otherwise, there is a NetworkMessage capture emitted following the TransportMessage, containing the network message header information specific to OPC UA PubSub. In special cases (such as with non-standard OPC UA PubSub extensions), there can even be more NetworkMessage captures for one TransportMessage.
(TBD)
(TBD - mapping auto-detection)
Capture type groupings
(TBD)
Name | Display Name | Description |
---|---|---|
NetworkTraffic | Network Traffic | A grouping of capture types. Contains all network traffic messages. |
AllPubSubMessages | All PubSub Messages | A grouping of capture types. Contains all OPC UA PubSub (terminal) messages. |
AllDataSetMessages | All DataSet Messages | A grouping of capture types. Contains all dataset messages (parsed and unparsed). |
AllDiscoveryMessages | All Discovery Messages | A grouping of capture types. Contains all discovery messages (probes and announcements). |
AllDiscoveryProbes | All Discovery Probes | A grouping of capture types. Contains all (parsed and unparsed) discovery probe messages. |
AllDiscoveryAnnouncements | All Discovery Announcements | A grouping of capture types. Contains all (parsed and unparsed) discovery announcement messages. |
All | All | A grouping of capture types. Contains all message types (non-terminal and terminal). |
Terminal and non-terminal messages
The capture types denote either non-terminal or terminal messages.
- non-terminal message
- The message is further structured and can contain other non-terminal or terminal messages. Consequently, there can be more captures arising out of a single non-terminal message.
- terminal message
- The message is not structured (or cannot be parsed) to further sub-messages. No further capture will be emitted for the terminal message.
Parsed and unparsed messages
Normally, the capture mechanism parses all parts of the message that are necessary to collect the information provided by the message. When the message or its part is encrypted, it is possible that the capture mechanism will not be able to decrypt (and parse) the full message contents, but will still be able to determine the type of the message and some PubSub header information. Such case is indicated by one of the unparsed capture types.
For more information to when the unparsed capture types are used, see Security and sniffing.
Capture header
(TBD)
Special cases
Security and sniffing
(TBD)
Data capture with sniffing
(TBD)
Transport message transformations
Some transports may not provide exactly the transport message received, but may transform it in some way. In such case, the OPC UA PubSub sniffer will not "see" the very original message as received, but will only be provided and see the transformed message data. This can happen, for example, if the transport provides and option to decompress the data.
Specifically: QuickOPC has an option to detect and auto-decompress data received in GZip format. This option is turned on by default in the MQTT transport, and turned off in the other transports (UDP, Ethernet). This means that when use use MQTT, and a GZip-ped message appears on the input, its capture data will already be decompressed in the TransportMessage capture. The fact that the data has been decompressed is indicated by the fact that the Compressed flag (property) is set in the Capture header.