OPC UA PubSub Sniffing concepts

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)

Non-terminal messages

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)

Terminal messages

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.

Capture type groupings

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.

See also

Using OpcCmd Utility as OPC UA PubSub Sniffer