Unable to read data from the transport connection: An established connection was aborted by the software in your host machine
Nadeeka
I have created a x509 self signed certificate and installed in my client
machine. The client machine runs a .net application which tries to pass data
to a java application through ssl. a java keystore is created from the x509
certificate and put to the server. a port is also specified in the java
application to listen to. I have below code
in the client code (c# code i have below statements)
private TcpClient tcpClient = new TcpClient(serverhostname, serverportPort)
;
SslStream sslStream= new SslStream(
tcpClient.GetStream(),
false,
new
RemoteCertificateValidationCallback(ValidateServerCertificate));
try
{
X509Certificate cert = new X509Certificate(certificateFile, certificatePwd)
;
X509CertificateCollection certColl = new X509CertificateCollection();
certColl.Add(cert);
sslStream.AuthenticateAsClient("publisher's name", certColl, System.Security.
Authentication.SslProtocols.Default, true);
// At this point we have established the secure TCP connection
tcpClient.NoDelay = true;
tcpClient.ReceiveTimeout = 100000;
}
catch (Exception e)
{
}
The below validation method passes true:
public static bool ValidateServerCertificate(
object sender,
X509Certificate certificate,
X509Chain chain,
SslPolicyErrors sslPolicyErrors)
{
if (sslPolicyErrors == SslPolicyErrors.None)
return true;
return false;
}
in the write method :
sslStream.Write(cmdBuf.buf, 0, cmdBuf.pos);
samConnection.Flush();
no error upto this point
Then comes the read method. in that i have as below:
rc = sslStream.Read(com.buf, offs, len);
offs += rc;
if (com.buf[offs - 1] == '\x0000')
done = true;
here the first time rc becomes zero. which means there's no data to be read
by the Read method. The second time "sslStream.Read" throws below error
contineuosly.
Error
=======
Unable to read data from the transport connection: An established connection
was aborted by the software in your host machine
Error code: 1053
SocketErrorCode: ConnectionAborted
I've been pulling my hair off trying to solve this issue. please help if u
have any clue.
Peter Duniho
> [...]
> Then comes the read method. in that i have as below:
> rc = sslStream.Read(com.buf, offs, len);
> offs += rc;
> if (com.buf[offs - 1] == '\x0000')
> done = true;
>
> here the first time rc becomes zero. which means there's no data to be
> read
> by the Read method.
When zero returns, it doesn't just mean "there's no data to be read". It
means the connection has been closed.
http://msdn.microsoft.com/en-us/library/system.net.sockets.networkstream.read.aspx
Nadeeka
1. how can I check weather the connection has been closed or not?
2. why does the write method not give any error? if the connection is not
there write method should give an error right?
3. does this hae anything to do with a fault in the certificates? (however
the authenticateAsClient gets through without any error)
Peter Duniho
> 1. how can I check weather the connection has been closed or not?
Try to read from the connection. If it returns 0, it's been closed
gracefully.
> 2. why does the write method not give any error? if the connection is not
> there write method should give an error right?
TCP supports full-duplex, including closures. In other words, a
connection has two directions in which it can be closed. Even if the
other end has closed the connection (resulting in 0 being returned by the
read method), the local end can continue to write until it closes its end
of the connection.
Note that all of the above is with respect to graceful closures. This
depends on each end using the appropriate shutdown method to actually
perform the initial close (e.g. Socket.Shutdown()). If you forcefully
close the connection, then the behavior is different: either a read or a
write to the connection will fail with an error.
> 3. does this hae anything to do with a fault in the certificates?
> (however the authenticateAsClient gets through without any error)
You haven't described any fault in a certificate, nor do I really know
that much about certificates anyway. So, I can't really say. That said,
assuming a _graceful_ closure and both endpoints implementing their
protocol correctly, no...a connection closure wouldn't cause any sort of
"fault".
Obviously a forceful closure, because it immediately interrupts data
transmission in both directions, could easily affect the data, preventing
anything that relies on that data from working.
Pete