OPC-UA Server Connection: Channel expired on connect

Ignition
1

Hi,

I’m using a OPC-UA connection to connect to an OPC server whos server time is different than the PC which is running Ignition. In my case, the difference is greater than the SecurityTokenLifetime (1 day). In this case, the OPC connection is not established, but “Faulted”. See log below.

Is this a bug in your OPC UA client stack?! Shouldn’t the check for channel renewal always be done with either the client or the server time?

Additional Infos:
[ul]
[li]SecurityPolicy is “None”, Message Security Mode is also “None”.[/li]
[li]Connections works if time of server and client matches.[/li]
[li]Connecting with other clients (Unified Automation UaExpert) works even with time difference.[/li][/ul]

Do you need further information?

Thanks for your help!

Best Regards

StatusCode[Severity=Bad, Subcode=Bad_TcpSecureChannelUnknown]: Channel expired. Created at Tue Apr 01 03:13:38 CEST 2014, lifetime=3600000, current time is Fri Apr 25 16:37:37 CEST 2014.
	at com.inductiveautomation.xopc.common.stack.UAChannel.processSymmetricChunk(UAChannel.java:869)
	at com.inductiveautomation.xopc.common.stack.UAChannel.processChunk(UAChannel.java:778)
	at com.inductiveautomation.xopc.common.stack.UAChannel.access$000(UAChannel.java:62)
	at com.inductiveautomation.xopc.common.stack.UAChannel$ProcessChunk.run(UAChannel.java:1581)
	at com.inductiveautomation.xopc.client.stack.SerialExecutionQueue$RunnableExecutor.execute(SerialExecutionQueue.java:100)
	at com.inductiveautomation.xopc.client.stack.SerialExecutionQueue$RunnableExecutor.execute(SerialExecutionQueue.java:97)
	at com.inductiveautomation.xopc.client.stack.SerialExecutionQueue$PollAndExecute.run(SerialExecutionQueue.java:75)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:722)
2

I understand this is frustrating, but I haven’t figured out a way to work around this in our client stack. The problem is that the security token for the channel, which contains the time the channel was created at, comes from the server. So the checks for whether the channel expired happen with one timestamp from the client system and the second timestamp from the server system. If the clock on the server is wrong enough then the channel will often expire immediately.

I’ll see if there’s anything I can do about this, but in the meantime you’ll just have to make sure the clock on your server is accurate within 1 hour, which is pretty generous. It doesn’t matter if they’re different timezones - the times in OPC-UA are all UTC-based. They just need to be correct-ish.

3

Just played around with it a bit - I may be able to include a change that makes this work in 7.6.7.

4

Thanks for your fast response.

I would really appreciate if you could fix this with version 7.6.7.
Wouldn’t it be possible to use the first time in the secure channel as starting point and ignore the check with the local client time. It would also be good if the use case would be supported, where the server changes its time settings and connection remains active.

Let me give you some background why this is important for us:
We integrate an OPC-UA server in our embedded devices and controls. These devices have the requirement to be “maintenance-free”. For example, all our controls are cooled passive and do not have any fans. Also, we can’t use batteries to power our realtime clock, when the device is not connected to a power source. To compensate for a power loss, we have some capacitors which can run the realtime clock for up to 10 days after the device is taken from power source. But if the device disconnected for more than 10 days, then the internal realtime clock resets to 1970.
So when taking the device right out of the box or from storage, then the clock has been reset most of the times. Not being able to connect to the device means not being able to set the current time which means you are locked out from your own device.

So this is why we need to be able to connect to an OPC-UA server with different time settings.

If you want me to test your patch, then feel free to ask.

Thanks again for your help!

PS: Your right, 3600000ms is 1 hour, not 1 day…