Change of system time leads to closing of secure channel

[gailjkm]

Type of issue

• Bug
• Enhancement
• Compliance
• Question
• Help wanted

Current Behavior

I am using the OPCUA-Library to connect a c# client application to a server on a Siemens plc.
The connection is up and running.
Values are asynchronously written to the plc with session.BeginWrite()

When I change the system time on the client side to at least 1 hour in the future, then the connection breaks instant.
A change of the system time to the past doesn’t have any effect, no matter how big the time difference is.

The system time could also be changed by the NTP client, in the case of a not initially correct set hardware clock.

The root cause is in the implementation of the timeouts. They save a timestamp and compared it with the current system time (DateTime.UtcNow). At the moment the system time gets changed, the timeout of the current token (and possibly an already prepared new token) for the secure channel gets triggered immediate and the secure channel gets closed.

Even with an automatic reconnect the current running publish events gets lost without any notification to the application.
The session and the subscriptions are transferred to a new secure channel, but failed publish requests are not cached and not retried.

Expected Behavior

The secure channel should not close and the connection should stay alive.
If this is not possible, the current publish tasks should not fail silently but be resent instead.
If this is also not possible at least an error notification should be sent to the application for each failing asynchronous write call.

Steps To Reproduce

1. Start a client using the opcua library
2. Set the system time of the client more than 1 hour into the future.

Environment

- OS: Windows 10
- Environment: Visual Studio 2017
- Runtime: .NET 4.6.2
- Nuget Version: 1.4.371.50
- Component: Opc.Ua.Client
- Server: Siemens PLC 
- Client:

Anything else?

Looks similar to issue #1859

[gailjkm]

Would it make sense to base the timestamping of the token on system time independent ticks?

There is the property Environment.TickCount or in newer frameworks the Environment.TickCount64, which counts the system timer continously forward. No matter, if and how far the system clock gets changed.
This would mean, the token ist valid for the given time, in my case 1 hour. The time span would always be 1h in real time, indepent from any system clock changes.

Would this be a reasonable solution, or is there on other places some need of the token.createdAt timestamp being actually current UTC time?

The source code concerned is

UA-.NETStandard/Stack/Opc.Ua.Core/Stack/Tcp/UaSCBinaryClientChannel.cs

Lines 1165 to 1167 in d65e1cf

	DateTime expiryTime = token.CreatedAt.AddMilliseconds(token.Lifetime);
	double timeToRenewal = ((expiryTime.Ticks - DateTime.UtcNow.Ticks) / TimeSpan.TicksPerMillisecond) * TcpMessageLimits.TokenRenewalPeriod;

The actual evaluation takes place at

UA-.NETStandard/Stack/Opc.Ua.Core/Stack/Tcp/ChannelToken.cs

Lines 72 to 83 in d65e1cf

	public bool Expired
	{
	get
	{
	if (DateTime.UtcNow > m_createdAt.AddMilliseconds(m_lifetime))
	{
	return true;
	}
	return false;
	}
	}

[gailjkm]

The solution in UA-.NETStandard/clock-independent-timeouts works for me in my environment.

See it as a proof of concept.
I have not yet created a pull request, because i am not sure about any negative side effects. Comments would be appreciated.

[mregen]

Thanks for the prototype. Planning to use the Stopwatch clock for #2457 / #2458.

[gailjkm]

Just adding some cross reference:
The topic is also worked on in issue #2546 for the current 1.5 series