Re: [milo-dev] Exceptions in Milo when subscribing to nodes in a Siemens

["Garcia Saez, Ignacio" <ignacio.garcia@xxxxxxxxxxxx>]

I was using 0.1.0 when I first met with these problems, then I updated it to 0.1.4 and finally to 0.1.5, but the same exceptions in all of them.

 

With the same source code I successfully subscribe to this older version of the server (encryption none, anonymous login). Its Server/ServerStatus/BuildInfo:

ProductUri: http://automation.siemens.com

ManufacturerName: Siemens AG I DT MC

ProductName: Sinumerik OPC UA

SoftwareVersion: 4.4.0

BuildNumber: 2

BuildDate: 2014-03-11T10:23:43.000Z

 

The problematic server BuildInfo is (encryption none, user&password login as it does not allow to enable anonymous login):

ProductUri: http://automation.siemens.com

ManufacturerName: Siemens AG DF MC

ProductName: Sinumerik OPC UA

SoftwareVersion: 4.6.2

BuildNumber: ??

BuildDate: 2016-09-30T09:53:43.000Z

 

My problems are with Milo and the new version, the one using the SDK?

 

But with a commercial client (UaExpert) it first displays:

Error ‘BadSecurityModeInsufficient’ was returned during ActivateSession, press ‘Ignore’ to suppress the error and continue connecting

 

And after ignoring, it can subscribe to nodes without any apparent problems.

 

Best regards

 

De: milo-dev-bounces@xxxxxxxxxxx [mailto:milo-dev-bounces@xxxxxxxxxxx] En nombre de Kevin Herron
Enviado el: martes, 07 de noviembre de 2017 14:46
Para: milo developer discussions <milo-dev@xxxxxxxxxxx>
Asunto: Re: [milo-dev] Exceptions in Milo when subscribing to nodes in a Siemens OPC server

 

What version of Milo are you using?

 

I think the only effective way to troubleshoot this will be to capture the exchange with Wireshark with security for the connection disabled.

 

My experience with the Siemens OPC UA servers in the SIMOTION and SINUMERIK products has not been good. I've been told they use an older, buggier, homegrown UA codebase in contrast to the new servers in the S7-1500, which use an SDK from one of the vendors.

 

 

 

On Tue, Nov 7, 2017 at 5:37 AM, Garcia Saez, Ignacio <ignacio.garcia@xxxxxxxxxxxx> wrote:

Hello,

 

I’m using the Milo package (0.1.5) to get data from a Siemens Sinumerik 840D SL numerical control, which comes with an OPC-UA server. In previous versions of the server I had no problem with the default channel configuration, but in most recent versions of the server several exceptions arose in the publish response:

 

10/05/2017 08:47:19.267 ERROR [ua-shared-pool-1] org.eclipse.milo.opcua.stack.client.handlers.UaTcpClientMessageHandler     - Error decoding symmetric message: max array length exceeded (length=310378496, max=65536)

org.eclipse.milo.opcua.stack.core.UaSerializationException: max array length exceeded (length=310378496, max=65536)

                at org.eclipse.milo.opcua.stack.core.serialization.binary.BinaryDecoder.decodeArray(BinaryDecoder.java:422)

                at org.eclipse.milo.opcua.stack.core.types.structured.PublishResponse.decode(PublishResponse.java:121)

                at org.eclipse.milo.opcua.stack.core.serialization.binary.BinaryDecoder.decodeMessage(BinaryDecoder.java:388)

                at org.eclipse.milo.opcua.stack.client.handlers.UaTcpClientMessageHandler.lambda$onSecureMessage$21(UaTcpClientMessageHandler.java:533)

                at org.eclipse.milo.opcua.stack.core.channel.SerializationQueue.lambda$decode$1(SerializationQueue.java:58)

                at org.eclipse.milo.opcua.stack.core.util.ExecutionQueue$PollAndExecute.run(ExecutionQueue.java:107)

                at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

                at java.util.concurrent.FutureTask.run(FutureTask.java:266)

                at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

                at java.lang.Thread.run(Thread.java:745)

 

It’s shocking the huge difference between the bytearray buffer size (65536) and the length received (310378496). I suspected there might be a bug in the server, but another commercial client subscribe to server nodes without problems.

 

I tried to avoid the problem using a non-default ChannelConfig:

                               final int SIZE_FACTOR = 1024;

                               final int CHUNK_FACTOR = 16;

                               ChannelConfig channelConfig = new ChannelConfig(

                                                               ChannelConfig.DEFAULT_MAX_CHUNK_SIZE*SIZE_FACTOR,

                                                               ChannelConfig.DEFAULT_MAX_CHUNK_COUNT*CHUNK_FACTOR,

                                                               ChannelConfig.DEFAULT_MAX_CHUNK_COUNT*CHUNK_FACTOR * ChannelConfig.DEFAULT_MAX_CHUNK_SIZE*SIZE_FACTOR,

                                                               ChannelConfig.DEFAULT_MAX_ARRAY_LENGTH*SIZE_FACTOR,

                                                               ChannelConfig.DEFAULT_MAX_STRING_LENGTH*SIZE_FACTOR);

 

Then I normally avoid the exception (not always, despite the 1024 factor), but then other exceptions appear:

 

4975 [ua-shared-pool-0] ERROR org.eclipse.milo.opcua.stack.client.handlers.UaTcpClientMessageHandler  - Error decoding symmetric message: readerIndex(106) + length(1) exceeds writerIndex(106): CompositeByteBuf(ridx: 106, widx: 106, cap: 106, components=1)

java.lang.IndexOutOfBoundsException: readerIndex(106) + length(1) exceeds writerIndex(106): CompositeByteBuf(ridx: 106, widx: 106, cap: 106, components=1)

                at io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1178)

                at io.netty.buffer.AbstractByteBuf.readByte(AbstractByteBuf.java:587)

                at io.netty.buffer.SwappedByteBuf.readByte(SwappedByteBuf.java:435)

                at org.eclipse.milo.opcua.stack.core.serialization.binary.BinaryDecoder.decodeDiagnosticInfo(BinaryDecoder.java:356)

                at org.eclipse.milo.opcua.stack.core.serialization.binary.BinaryDecoder.decodeArray(BinaryDecoder.java:428)

                at org.eclipse.milo.opcua.stack.core.types.structured.PublishResponse.decode(PublishResponse.java:121)

                at org.eclipse.milo.opcua.stack.core.serialization.binary.BinaryDecoder.decodeMessage(BinaryDecoder.java:388)

                at org.eclipse.milo.opcua.stack.client.handlers.UaTcpClientMessageHandler.lambda$onSecureMessage$20(UaTcpClientMessageHandler.java:534)

                at org.eclipse.milo.opcua.stack.core.channel.SerializationQueue.lambda$decode$1(SerializationQueue.java:58)

                at org.eclipse.milo.opcua.stack.core.util.ExecutionQueue$PollAndExecute.run(ExecutionQueue.java:107)

                at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

                at java.util.concurrent.FutureTask.run(FutureTask.java:266)

                at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

                at java.lang.Thread.run(Thread.java:745)

 

At this point I don’t know what to do. Please find attached a full log of an attempt to subscribe to a single node of the server in case you find it useful (with enlarged ChannelConfig). I can provide my code using milo if required, but as you probably don’t have that type of server available, I’d test any hack by myself.

 

Thanks in advance

 

Ignacio Garcia

_______________________________________________
milo-dev mailing list
milo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/milo-dev