Link Status Failure

[Nicholas Lee]

I've read the Link-Layer documentation for opendnp3, and have read similar threads in this forum on the subject, but I'm still a bit confused about link status requests, and how I should be handling them in my outstation.

I have observed the following behaviour:

• On link status timeout, my OnKeepAliveFailure function gets called, as expected.  The channel stays open, even after many such failures.
  
• On recovery of the network from whatever conditions caused these failures, the channel closes (connection reset by peer), and my OnStateChange(UNRESET) function gets called.
• When the channel reopens, I get another OnStateChange(UNRESET) call.
• Link status requests then continue, and my OnKeepAliveSuccess function gets called for each one, but OnStateChange(RESET) never occurs.

The documentation suggests that I should be closing the channel when my OnKeepAliveFailure function gets called.  Should I be doing this after three successive failures?

Under what circumstances does OnStateChange(RESET) occur, as I've never seen it?  Ideally, OnStateChange(UNRESET) would get called by opendnp3 itself after three link status failures, and OnStateChange(RESET) would get called when the link is verified to be working again (whether that be from a successful unsolicited or solicited response, or another link status request).

Some guidance would be welcome.

Thanks,

Nick

[J Adam Crain]

Hi Nick,

The link (reset/unreset) mechanism and the KeepAlive functionality (Link status) are completely unrelated.

The RESET/UNRESET mechanism reports whether the local link layer has reset the remote link layer.  If you're only using UNCONFIRMED data transfer you'd never actually see the RESET state:

https://github.com/automatak/dnp3/blob/b8d3f99fd79ecd7960ad95605ba11a03988c0d58/cpp/libs/src/opendnp3/link/PriLinkLayerStates.cpp

This code and feature was actually added by your master team. It's not something that most people need.

Regarding the link status (which I typically call "heartbeat" because that's what it is), the reason that opendnp3 doesn't automatically close the connection when the link status request fails is that the standard doesn't define what you're supposed to do when it fails. We left it up for the user to decide how they wanted to handle it. In most cases, just the act of writing to a failed socket will cause the underlying TCP stack to close, i.e. one of the link status writes will eventually fail.

-Adam

[Nick Lee]

Adam,

I was  under the impression the DNP3 Specification said the connection should be dropped on link status request timeout, but I can no longer find it (at least, not in the latest specification: it's in an earlier one, so maybe they dropped this requirement?)

Under what circumstances does OnStateChange(RESET) occur, as I've never seen it?

I've also been doing some testing with link status requests and the timeout doesn't seem to always correspond to the frequency of the requests - for example, with a 30s timeout, I'm seeing link status requests every 60-90s.  I've confirmed with tcpdump that there's no other DNP3 traffic, so it's not that the timeout is being reset by normal traffic (indeed, does opendnp3 do this anyway?)

Nick

--

Nicholas Lee | Embedded Software Engineer
Office : +44 (0)8700 111992   Email/Lync : nick...@nortechonline.co.uk
Nortech Management Ltd Unit 2, Deer Park Business Centre, Woollas Hill, Eckington, Pershore, WR10 3DN, United Kingdom
Company website: www.nortechonline.co.uk
Registered in England no: 2777816 VAT No: GB606132871

[J Adam Crain]

Hi Nick,

I'll have another look at 1815-2012 when time permits.

The LinkStatus mechanism does the "reset timer on valid packet" optimization. In other words, it doesn't send packets at a fixed interval. It waits for a certain IDLE time to elapse before sending. If there's traffic like periodic polling, you're not supposed to ever see it.

Regarding the interval not matching the configured value, can you open a ticket on github for me to review?

We need to do another release soon that merges from the feature branch and fixes a few small issues.

thanks,

Adam

[Abhi]

Hi Adam,

I have been looking into this issue aswell. The DNP3 Spec in "4.3.3.2 Broken Connections" mentions that "Listening end point - close connection and
commence listening for new connections." when there is no response for a keep alive timeout.

I scanned through the code and understand that the disconnect request show go in LinkContext::FailKeepAlive(). Could you confirm what method should be called here to disconnect/close the socket.

Also, I believe the LinkStatusListener does not have a JNI Adapter defined, hence callbacks are not received in Java.

[Abhi]

Adam,

I did add KeepAlive callbacks to the OutstationApplication's JNI. For now the solutions seems to be enable and disable the outstation. Is there a better method to do it without pausing communication?

Best,
Abhi