Log In
Home
11/29/2018
Offline
Hello,
I must be missing something.
Table 57, has the request header followed by the client protocol version. “RequestHeader” has as the last field, additionalHeader but the data I am seeing is not formatted as described.
WireShark has it dissected as:
TimeoutHint: 0 <- Here and before, found in the specification.
——————— Cannot find in the specification
AdditionalHeader: ExtensionObject
TypeId: ExpandedNodeId
EncodingMask: 0x00, EncodingMask: Two byte encoded Numeric
…. 0000 = EncodingMask: Two byte encoded Numeric (0x0)
.0.. …. = has server index: False
0… …. = has namespace uri: False
Identifier Numeric: 0
EncodingMask: 0x00
…. …0 = has binary body: False
…. ..0. = has xml body: False
—————— Cannot find in the specification
ClientProtocolVersion: 0 <- Found in the specification.
I found data about ExtensionObject, but not in the specification concerning OpenSecureChannel service.
Anyone point me to the correct specifications text or other data/idea?
Thanks,
Mark
05/30/2017
Offline
The ExtensionObject is in Part 6:
https://reference.opcfoundatio…..s/5.2.2.15
OpenSecureChannel for UA TCP is defined here:
11/29/2018
Offline
Thanks for the response.
Yes, I had found those references. What I have not found is where in 6.7.4 that object type is called out to be used. What is the name in the “Request” (Table 57) that uses the object?
I am beginning to think it is used for a lower level but no joy in finding the documentation.
05/30/2017
Offline
What part of this text is unclear?
Most Messages require a SecureChannel to be established. A Client does this by sending an OpenSecureChannel request to the Server. The Servershall validate the Message and the ClientCertificate and return an OpenSecureChannel response. Some of the parameters defined for the OpenSecureChannel service are specified in the security header (see 6.7.2) instead of the body of the Message. Table 57 lists the parameters that appear in the body of the Message.
Note that OPC 10000-4is an abstract specification which defines interfaces that can work with any protocol. This document provides a concrete implementation for specific protocols. This document is the normative reference for all protocols and takes precedence if there are differences with OPC 10000-4.
11/29/2018
Offline
Thanks for the response.
What part of this text is unclear?
In reference to OpenSecureChannel, which parameter, in any table or text, has “ExpandedNodeId” (ExtensionObject) for the this:
AdditionalHeader: ExtensionObject
TypeId: ExpandedNodeId
EncodingMask: 0x00, EncodingMask: Two byte encoded Numeric
…. 0000 = EncodingMask: Two byte encoded Numeric (0x0)
.0.. …. = has server index: False
0… …. = has namespace uri: False
Identifier Numeric: 0
EncodingMask: 0x00
…. …0 = has binary body: False
…. ..0. = has xml body: False
Or is this object required at a different level and if so can you point me to the location in the specification?
05/30/2017
Offline
It appears Wireshark has a bug (or a feature).
ExtensionObject.TypeId is NodeId – not an ExpandedNodeId.
The actual bytes on the wire match the encoding needed for a NodeId.
11/29/2018
Offline
Thanks for the response.
OK great. Where in the specification does it state that a node ID is to be placed between:
TimeoutHint: 0 <- Here and before, found in the specification.
<node id here>
ClientProtocolVersion: 0 <- Found in the specification
I can point to the exact location in the specification where TimeoutHint and ClientProtocolVersion are required. A node ID between the two is not specified at that location or any other data.
Perhaps another part of the specification says a node ID is to be placed before X. I am seeking the location in the specification that states it.
05/30/2017
Offline
https://reference.opcfoundatio…..docs/5.3.5
Structures are encoded as a sequence of fields in the order that they appear in the definition. The encoding for each field is determined by the built-in type for the field.
All fields specified in the structure shall be encoded. If optional fields exist in the Structure, then see 5.2.7.
So the ClientProtocolVersion immediately follows the RequestHeader which is defined here:
https://reference.opcfoundatio…..ts/2/17087
The AdditionalHeader field is preceded by the TimeoutHint.
AdditionalHeader is an abstract type “Structure” which means it is encoded a ExtensionObject which includes a TypeId to indicate what is actually encoded.
11/29/2018
Offline
Thanks for the reply.
Are you saying the “additionalHeader” field of the “RequestHeader” is the “ExtensionObject” and if there is an additional header or not the “typeID” must be included?
If so, that is what I thought but, that is not defined, (spelled out) in the specification. It says “Applications that do not understand the [additional] header should ignore it.” = read the typeID so you know what (size) to ignore.
11/29/2018
Offline
And, do you know of any instance in the specification where the “additionalHeader” is used?
05/30/2017
Offline
RequestHeader -> AdditionalHeader is encoded as an ExtensionObject
ExtensionObject -> TypeId, EncodingMask, Body
See https://reference.opcfoundatio…..docs/6.8.2
OPC 10000-4defines AdditionalParametersType which is a list of name-value pairs. An instance of this type is passed in the AdditionalHeader field. Instances of the EphemeralKeyType defined in OPC 10000-4 are passed as values in the name-value pair list in the response messages. The names used for the parameters defined for the CreateSession/ActivateSession exchange are defined in Table 63.
11/29/2018
Offline
Thanks for the response.
OK so it is a null “nodeID”.
1 Guest(s)
Usage Policy