OPC UA PubSub Sniffing concepts
Contents
Introduction
The sniffing mechanism for OPC UA PubSub allows you to observe network traffic that relates to OPC UA PubSub, and to certain degree, inspect and analyze the contents of the messages. Its uses can be e.g.:
- To discover which OPC UA PubSub participants are active on the network, and what kind of information they provide.
- In some phases of automated OPC UA PubSub discovery process.
- To capture the received message data, for troubleshooting, or for processing of non-standard messages.
The OPC UA PubSub Sniffing is not a substitute for a low-level network analysis, such as that provided by WireShark. Its purpose is somewhat different. Specifically, the OPC UA PubSub Sniffing is not meant to be always able to help with issues related to conformance with OPC UA standards. If the messages received are badly malformed, OPC UA PubSub Sniffing may have problems analyzing them, and that is OK. The OPC UA PubSub Sniffing is designed to help with configuration issues and traffic analysis of otherwise correctly written and operating software.
Capture types
Each notification emitted by the OPC UA PubSub sniffer is qualified with a specific capture type. The capture types available correspond to types of OPC UA PubSub messages, and are described further below. When subscribing to notifications from the OPC UA PubSub sniffer, you can specify which capture types you are interested in. By default, all capture types are emitted.
Capture type "None"
A notification with a special capture type None is emitted when the specified underlying transport used by the OPC UA PubSub sniffer successfully connects to the messaging infrastructure. It is typically the first notification that you received from the sniffer. You can also receive it later, in case of a re-connection.
Individual capture types
(TBD)
| Name | Display Name | Description |
|---|---|---|
| TransportMessage | Transport Message | A non-terminal message. Represents a full original message, as received by the transport mechanism. |
| NetworkMessage | Network Message | A non-terminal message. Represents a data or discovery message defined by OPC UA PubSub. |
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)
| Name | Display Name | Description |
|---|---|---|
(TBD)
Capture type groupings
When you are specifying to the OPC UA PubSub Sniffer which messages you are interested in, you will often need a combination of several individual capture types. The commonly used combinations are called capture type groupings, and are available under their own names.
| 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). |
- NetworkTraffic
- This grouping is an opposite of AllPubSubMessages. It is useful when you are interested in the basic physical characteristics of the messages, such as which network traffic is actually present, whether it is actually an OPC UA PubSub traffic, and eventually "who is publishing (or discovering)".
- AllPubSubMessages
- This grouping is an opposite of NetworkTraffic. It is useful when you are not interested in the physical characteristics of the messages, but only in their logical meaning with regard to OPC UA PubSub.
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 features and considerations
Message mapping
For the OPC UA PubSub sniffer to be able to analyze the messages, it needs to know their message mapping (which includes message encoding). Currently, OPC UA PubSub defines two message mappings: UADP (binary), and JSON. The message mapping is specified to the OPC UA PubSub sniffer by the means (as part of) the transport profile URI. If the message mapping specified to the OPC UA PubSub sniffer does not match the actual mapping used in the received messages, the OPC UA PubSub sniffer will only recognize and emit the transport messages (TransportMessage capture type), but no network messages (NetworkMessage capture type) and other, more detailed capture types.
Thankfully, QuickOPC has a feature that can recognize the message mapping of the received messages automatically, on the fly (and is using its own, special transport profile URIs for that). This feature is on by default whenever an MQTT transport is used, but you can turn it off by specifying one of the standard transport profile URIs for the PubSub connection. The auto-recognition works on a message-by-message basis, which means that not only is the proper message mapping recognized once, but it can actually differ with each message. This comes handy with subscriptions to MQTT topic trees (using topic filters), where some topics may contain messages published in UADP, and some in JSON.
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 an 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 you 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.
