Connection was forcibly closed by the remote host

[WimVriend]

Hello Kevin,

Another question, maybe/probably not related to my other post. When communicating via the 1756-EN2T  of our PLC, every now and then we get this message:

Do you have any idea what might cause this and is there something we can do to prevent it?
Communication does not seem to be hindered by it.

[kevinherron]

This means the controller has closed the TCP connection.

I think one scenario this can happen is when the connection is idle/unused (no requests sent) for too long, perhaps longer than the negotiated CIP connection timeout, or longer than some timeout of the underlying ENIP session.

It might be interesting to look at a Wireshark capture of traffic between the host and controller leading up to one of these occurrences.

[WimVriend]

Hello Kevin,

Thanks for your quick reply. Is there a way to capture this error, so it can be processed (written in our log, for example) instead of ending up in the output? You don't think it's problematic?

[kevinherron]

EtherNetIpConfig accepts a Consumer<Bootstrap> that you might be able to use to add your own Netty channel handler to, which would hopefully get ChannelInboundHandler::channelInactive and ChannelInboundHandler::exceptionCaught called on it. If that doesn't work there's no way to "catch" it in your application right now.

You don't think it's problematic?

It's a small problem. "Normal" operation doesn't see these errors. I don't know what about your environment would cause the other end to close the connection. If you don't actually notice any disruption it's probably because the library immediately reconnects without issue.

[kevinherron]

Oh, another reason you might see this happen is when a download to the controller happens.

[WimVriend]

Hello Kevin,

I will ask my colleagues to make a note of the time, when they perform a download: then we can easily check that.
Indeed I do suspect that it is just that...