I'm getting a "Socket Error: Connection reset by peer" message using the tradeclient c++ demo code from the quickfix download.
another user commented that it was related to network issues. if anyone has the solution it would be appreciated.
QuickFix C++ Socket Error Connection Reset By Peer?
<20141221-17:32:11.049, FIX.4.4:myusername->hostusername, event>
(Created session)
<20141221-17:32:11.056, FIX.4.4:myusername-> hostusername, event>
(Connecting to fix.hostusername.com on port 5001)
<20141221-17:32:11.221, FIX.4.4:myusername-> hostusername, outgoing>
(8=FIX.4.49=10735=A34=149=myusername =20141221-17:32:11.21856= hostusername 98=0108=30141=Y10=000)
<20141221-17:32:11.221, FIX.4.4:myusername-> hostusername, event>
(Initiated logon request)
<20141221-17:32:11.253, FIX.4.4:myusername-> hostusername, event>
(Socket Error: Connection reset by peer.)
<20141221-17:32:11.253, FIX.4.4:myusername-> hostusername, event>
(Disconnecting)
think i found the reason. the host I'm trying to connect with is using quickfix java which supports SSL. the quickfix c++ client doesn't seem to support the SSL enable tag in the session settings. finally had to resort to wireshark to determine this. i searched all over the web and many people were reporting this similar error. i hope this post saves them any anyone in the future from debugging endlessly to solve this "Socket Error: Connection reset by peer" error.
Two reasons I am aware of for "Socket Error: Connection reset by peer" are:-
1) Your SenderCompId/TargetCompId does not match with that of other side. In that case just make sure you are using correct one.
2) Other one is that sequence number expected by server is something different what you are sending. In that case just try with ResetOnLogon field ( in your registry file )to No and check if that resolves the issue.
There can be many reasons for this error. However, I doubt it that network is responsible for this error as connection request has been sent to server properly. You could search through the internet for wider range of answers.
Could well be firewall, have you the right IP and port, and permission to get there?
think i found the reason. the host I'm trying to connect with is using quickfix java which supports SSL. the quickfix c++ client doesn't seem to support the SSL enable tag in the session settings. finally had to resort to wireshark to determine this. i searched all over the web and many people were reporting this similar error. i hope this post saves them any anyone in the future from debugging endlessly to solve this "Socket Error: Connection reset by peer" error. – geiger zaehler
We got this error message when we had not correctly imported the security certificate.
Related
I'm writing server application which uses boost::asio, and libssl via its integration with boost::asio. When there is incoming connection, the first time the handshake succeeded, but after the connection is dropped and the client tries to connect again, the handshake fails with the error:
session id context uninitialized
Here has proposed solution with using SSL_OP_NO_TICKET option when the SSL context is initialized. I'm using it the following way:
m_sslContext.set_options(SSL_OP_NO_TICKET);
In the beginning this resolves the problem, but now despite the option is still set the error appears again. Does anybody has an idea what other can be done with this problem?
I found that when the problem arises I still have an old connection to the same remote endpoint which tries to connect again. When I dropped the old connection properly the problem gone.
I got exactly the same error with client certificate verification enabled.
The solution was to create separate ssl_context for every connection, unlike in boost.asio examples.
One thing to note, SSL stream shutdown never completed in my case, it just would hang indefinitely. Perhaps, because the client didn't implement it correctly.
There are so many questions about this issue but none has been able to address my issue specifically and I have yet to find any valid explanation of the error itself:
The underlying connection was closed: The connection was closed unexpectedly
In our situation we are making a call to a 3rd Party API via SSL. On my local PC I can connect to that API make a request and get a response back, but on an IIS Production server I get this error. The API is using OAuth to authenticate.
What exactly does it mean. Is the request leaving our server and rejected by the remote server, or is it not even leaving our server and our system is preventing it from making the request.
Some more information incase anyone may know what the issue is:
No known changes to any networking, servers, routing, security (apparently)
No code changes recently
According to our own internal logging, the issue started off as an ocassional 403 Error-Forbidden then we saw a number of Cannot Connect to Remote Server. Eventually it failed with The underlying connection was closed: The connection was closed unexpectedly.
Can someone please explain what the actual error means? If anyone has experienced this in a similar situation and can shed some light, that would be greatly appreciated.
The underlying connection was closed: The connection was closed unexpectedly
This just says, that (probably the remote end) closed the TCP connection which underlies the SSL connection. Usually an SSL alert should be sent back on SSL related errors, but some stacks instead close the connection. It might also be that the peer does not expect SSL at all and thus closes the connection because of invalid data.
On my local PC I can connect to that API make a request and get a response back, but on an IIS Production server I get this error.
It is hard to say what the problem might be, but if this is not only the same API but also the same server then the problem must be related to differences in the client. This can be support in ciphers, TLS versions, client certificates etc which can be different between machines. If this is not even the same server you should make sure that the problem is not server related by contacting the non-working server with the working client.
A good idea is also to make a TCP dump (wireshark) and compare the handshakes.
More detailed problem analysis can only be done when you provide more details about the problem, see http://noxxi.de/howto/ssl-debugging.html#hdr2.2 on what might be useful information.
I'm sorry if my question was answered already, but I cannot find it yet.
I'm using C++ and connection pool to connect to a PostgreSQL database in a Win32 console application. It runs OK at the beginning. However, after a while the program received an error: "Server closed the connection unexpectedly. This probably means the server terminated abnormally before or while processing the request".
When I open the PostgreSQL log file, it shows message: "unexpected EOF on client connection, could not receive data from client: No connection could be made because the target machine actively refused it."
Thank you for any help.
This really sounds like a network problem. I would be looking first at firewalls, then switches. I don't think a cable or a bad network card could cause a problem like this.
What sounds like is going on is that a connection is getting reset. If you eliminate network issues, then the next area to blame is the connection pooling software. Look at switching this out and see if the problem persists.
I'm trying to setup a connection to FTP to transfer a file. Unfortunately, because of the environment the tools I have available to me are limited.
I'm receiving the following error:
An error occurred while establishing an FTP connection.
Error: Connection refused: connect.
Does this mean that I can reach the FTP server but the credentials are incorrect? Does it mean that I can't reach the server at all? Or is there no way to tell?
Update: I changed the IP address I was using to some other random number, so it's almost certainly because I can't connect. I wish there was a way to tell the difference between connectivity and authorization issues.
A "Connection Refused" error means that either the server you're trying to connect to isn't running an FTP server, or there's a firewall in your way that's preventing the connection.
An "User Authentication failed" error would usually occur if your credentials are bad.
FYI, for plain old FTP connections, the cfftp.errorCode may give you more information, once your are able to establish a connection. The errorCode will point to the response in the IETF FTP protocol standard , like "425", which would mean "Can't open data connection.".
Could be either one of those cases. Do you have a standalone FTP client to test with? Does it work from another machine?
hey check if your directory attribute is begining with a "/" character. this used to work through cf8 but stopped working for me in cf9 (specifically 9.0.1);
also try the following and see if this helps:
<cfftp connection="mycon" server="myserver.com" action="open" username = "anonymous" password = "anonymous" />
<cfdump var="#mycon#" label="">
<cfftp connection="mycon" action="getcurrentdir" result="result"/>
<cfdump var="#result#" label="">
you may find that its the listdir that is giving you the problem, not the connection.
You can check your ability to connect to the FTP server using Telnet at the command prompt(On windows, Go to Start > Run > type cmd).
telnet my-domain-name.com 21
you can try at non default port as you wish. That will let you know if your machine can reach the FTP server, and you can try logging on to check your credentials.
Here's a good post: Understanding FTP using raw FTP commands and telnet
Quite new to boost and asio, need help:
connect to proxy
asio::ip::tcp::socket socket_;
send CONNECT host: ssl server to the proxy
receive response 200
asio::ssl::context ctx(io_service, asio::ssl::context::sslv23);
sslsocket_(socket_,context)
try handshake
sslsocket_.async_handshake(asio::ssl::stream_base::client, boost::bind(&client::handle_handshake, this, asio::placeholders::error));
and get asio.ssl error
Wireshark: host sends FIN after 1st message of handshake
Direct async connection to ssl server works fine, same through Proxifier
You'll probably need to examine the OpenSSL error stack in step 5, which isn't terribly easy since Boost.Asio doesn't map it into the normal system_error codes that it uses. There was a post by Guy Sirton recently on the asio mailing list describing how to modify the source to accomplish this.
Forgot to mention that was running the application in VMplayer with NAT network; bridged removed the problem with initial handshake but sometimes after reconnect saw the same message;
using the method in Sam's link got to "unexpected record" during handshake - google said on this error about renegotiations but that was not the case; digging into sources of OpenSSL: the new connection used the same BIO for reading and recevied application data from previous connection
Don't know how to reset the SSL structure with asio, so made dynamic socket allocation with new|delete