Link Confirm Strangeness

[Nicholas Lee]

I posted something similar a while back (see "Link Status Failure"), but it seems I forgot to raise the related case about unexpected link status period behaviour.  I'm still getting the same unexpected behaviour with opendnp3 3.1.1.

I've got an outstation with a link status period of 60s, and no events being sent over dnp3.  I've turned off link status period on the host.  The host isn't doing any polling.  So the link is quiet, except for periodic link status requests.  However, I'm getting link status requests precisely every 120s (whatever link status period I choose, the actual link status request frequency is double).

I've put some debug in the library to try and isolate the problem.  An example sequence is:

LinkContext::OnKeepAliveTimeout(): not elapsed (59) < this->config.KeepAliveTimeout(60)
LinkContext::StartKeepAliveTimer(15531)
LinkContext::OnKeepAliveTimeout()
LinkContext::OnKeepAliveTimeout(): elapsed (119) >= this->config.KeepAliveTimeout(60)
LinkContext::StartKeepAliveTimer(15591)
LinkContext::CompleteKeepAlive()

I can't quite figure out where the fault (if indeed it is a fault) lies.  It seems that the timeout expires slightly early, which it correctly realises hasn't actually expired, but then it starts another timeout of 60s duration.  A library modification making it restart the timeout with 0.5s duration if it hasn't actually expired 'fixes' the link status period to 60s.  However, maybe the root cause is the original timeout expiring slightly early?

Any advice appreciated!  I'm happy to fix it once we've established which bit needs fixing.

Nick

[Émile Grégoire]

Hi Nicholas,

I already wrote a fix for this in PR #407 (https://github.com/dnp3/opendnp3/pull/407). The same issue was described here: https://github.com/dnp3/opendnp3/issues/392

Can you try out this branch and see if it properly fixes your issue? I don't remember why I never merged it, we were maybe waiting for feedback.

Émile Grégoire, P.Eng.

Software Engineer

Step Function I/O

[Nicholas Lee]

Émile,

Apologies for not spotting issue 392.  I did search, but clearly not very successfully!
I've tried PR #407, and can confirm it works as expected (mostly, but see below): the link confirm requests are now at precisely the interval I've configured.

However, I've put a bit of debug in the library, and have noticed internally the timer still expires slightly early all the time.  This is on Linux, which definitely has a monotonic clock, so I'm not sure why this should be.  A typical example is the timer expiring at time 59976 for a keep alive timeout of 60000, followed immediately by another expiry time of 60001.

In the first instance, could you merge PR #407 into main please?  But it would be also good to understand why the timers are expiring early as well.

Ideally we could do with a proper release, but a milestone would be good enough for now.

Thanks,

Nick