We are seeing the following error in Diagnostics about every 5 seconds. Any idea where this can be coming from?
Unhandled error when processing request from client
System.IO.IOException: Authentication failed because the remote party has closed the transport stream.
at System.Net.Security.SslState.StartReadFrame(Byte buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
at Pipefish.Transport.SecureTcp.Server.SecureTcpServer.ExecuteRequest(TcpClient client) in y:\work\3cbe05672d69a231\source\Pipefish.Transport.SecureTcp\Server\SecureTcpServer.cs:line 112
It looks like you might have polling Tentacles trying to contact the Octopus server (usually on port 10943). We don’t log the IP address of where it’s coming from at the moment, but we will in a future version. Using netstat or TcpView on the Octopus server might help to shed light on who’s calling in.
Yes, we do have one polling tentacle, so it’s easy to know which one this is. But what does the error itself mean, and how should we go about solving it? Is it a software issue, or a networking issue?
What happened is:
- The polling Tentacle (or something else) connected to the Octopus server on that port
- Octopus server began the SSL handshake
- The polling Tentacle (or something else) terminated the request before the handshake was complete
This can happen for three reasons:
- When the Octopus server identified itself, the polling Tentacle compared the Octopus thumbprint to the thumbprints that it trusts, and decided that the Octopus server wasn’t what it expected. In other words, it’s a configuration issue. If the polling Tentacle appears offline in Octopus, this is why.
- The network timed out or some other network issue during the SSL handshake
- It was something else, not the polling Tentacle (perhaps another that was set up and forgotten, or some kind of network probing software).
Hope this helps,
Indeed - we fixed this by finishing the configuration of our Polling tentacle.