Slave stops listening on port after TCP channel is disconnected

[nikola.b...@gmail.com]

Hi all,

I have recently migrated my solution to 3.1.0 version and now I'm encountering a problem when TCP connection is shutdown. Slave receives channel Closed state, tries to set it to Opening and then something happens inside the library and I receive following error:

[Dnp3Sim] Connection connX, port=12345 changed state to CLOSED

[SlaveManager] - OnDisconnect: Connection= connX  , Address=0.0.0.0, Port=  12345  disconnected

[Dnp3Sim] Connection  connX  , port= 12345  changed state to OPENING

[Dnp3] The I/O operation has been aborted because of either a thread exit or an application request.

After this, slave stops listening on this port and no new connection can be established until I restart the slave. My solution needs to support redundant master instances (hot/stand by) and it worked fine with previous version of opendnp3. 

Does anybody have a clue what might be the problem? Is there some new configuration that I'm not aware or is something needs to be set to support regular reconnect? Thank you in advance!

Best regards,

Nikola 

 

[nikola.b...@gmail.com]

Wireshark traffic is provided in the attachment

[nikola.b...@gmail.com]

Additionally, lower log level shows that before receiving "Opening", opendnp3 published LinkStatus.UNRESET:

[Dnp3Sim] OutstationApplication - OnStateChange: rtuName = conX, linkStatus = UNRESET

[Adam Crain]

Which language?

In C# / Java a common mistake is to let the DNP3Manager be garbage collected which shuts down the stack.

[Nikola Bajić]

I'm using C#, but this is not the use case. DNP3Manager is not being GC-ed, instance is alive during the whole APP lifecycle. I have other connections alive and running at the same time and everything is working fine. Whenever I shutdown one specific connection from TCP View, it's port stops listening on the slave side and I receive aforementioned exception:

[Dnp3] The I/O operation has been aborted because of either a thread exit or an application request.

--
You received this message because you are subscribed to a topic in the Google Groups "opendnp3" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/automatak-dnp3/ub3S4AeVedU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to automatak-dnp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/automatak-dnp3/7961e14f-268a-4e02-aa6d-b09513b5c8d8n%40googlegroups.com.

[Adam Crain]

How does the outstation behave if the socket is gracefully closed by the client, as opposed to forcibly closed via TCP View?

[Nikola Bajić]

Same thing is happening. That is the original use case of how I reproduced the problem. Master is disconnecting to allow standby master to connect and after the disconnect, a new instance is not able to connect. By looking at TCP view, I have noticed that no slave port is listening anymore. I tried with one connection using TCP disconnect and experienced the same problem. 

To view this discussion on the web visit https://groups.google.com/d/msgid/automatak-dnp3/fca09189-f377-4fb1-a56a-3148107778bdn%40googlegroups.com.

[Nikola Bajić]

I have found a problem. It was part of my implementation of connection listener and it was disabling outstation when specific sequence channel states are received. 

You can close the thread. 

[Adam Crain]

Thank you for letting us know that you found the reason for the issue you were having.