I'm using Google's simplehttp2server go-lang program to run some tests and have encountered a recurring error. Upon executing the TLS handshake I receive the following error:
2019/12/12 12:42:55 http: TLS handshake error from 127.0.0.1:36202: read tcp 127.0.0.1:5000->127.0.0.1:36202: use of closed network connection
I have updated my go version to 1.13.5 from 1.12.9 and tried two browsers (brave + chrome) plus curl and receive the same error code each time. It happens over HTTP/2 and HTTP/1.1. I have seem other answers from across the web but am still running into this error (ex1, ex2, ex3, ex4).
Very much appreciate any feedback, advice, or admonishment. Anything to help the migraine this problem is giving me!
edit: screenshot from my curl and running of simplehttp2server
example image from curl and simplehttp2server
This error happens when you have two websockets connected to a singular address using the same port from the same machine. One of the websockets will be able to connect fine but the other wont be able to make the connection.
I was making the same mistake and when I removed the duplicate connection the error resolved.
Related
Problem Description
When I was using Node.js and generated the file package.jons, I found there's a warning at the start:
Problems loading reference 'https://json.schemastore.org/package': Unable to load schema from 'https://json.schemastore.org/package': Failed to establish a socket connection to proxies: ["SOCKS5 127.0.0.1:1090","SOCKS 127.0.0.1:1090"].
Possible Reason
Then I searched the error message Failed to establish a socket connection to proxies, and found maybe it's a wsl2 proxy problem according to this github reply.
For more precise reason, I searched the VSCode proxy document metioned by the reply, and found maybe it's caused by wrong proxy setting.
Ways to try
According to the VSCode document, I want to try the setting of "Manual proxy address". But I encountered two problems:
I don't know how to run the command line mentioned in the VSCode document: --proxy-server=<scheme>=<uri>[:<port>][;...] | <uri>[:<port>] | "direct://".
I don't know where to find the file /etc/resolv.conf mentioned in the github reply to get the wsl server ip.
When I switch my VPN into global mode and restart VSCode, the warning disappear.
Im running a Laravel 6 app on AWC EC-2 instance and have it configured to send mail via Gmail SMTP. Has worked perfect for nearly 2 years. Approx 1-1.5 days ago, the email function started throwing the Connection timed out error.
I tried switching ports, and changing TLS to SSL and no change.
Ive read dozens of threads with the same problem - but no help. Most suggest changing from driver smtp to sendmail - but that breaks all my email-send code.
I tried to telnet smtp.gmail.com 587 from the command line - and get Host is unreachable. There has been NO change to the code, config or setup recently.
My thoughts right now, are either:
AWS have blocked my smtp port,
Google has blocked my IP from sending mail,
My server MAY have reached a limit of some sort (but thought it will un-suspend in 24hrs if the case)
I am not sure HOW or WHERE to find that answer, or if there is another possible problem/solution here. I only have Basic support with AWS - so cant raise a standard tech support q.
Any suggestions would be greatly appreciated.
With thanks - James (Image of error and env below).
I see errors like this when issuing ddev commands:
segment 2020/03/31 11:30:15 ERROR: sending request - Post https://api.segment.io/v1/batch: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
segment 2020/03/31 11:30:15 ERROR: 2 messages dropped because they failed to be sent and the client was closed
Does it matter? What can I do about it?
This is usually a result of either really bad internet or pi-hole (or similar DNS interceptor) being active and preventing proper lookup of api.segment.io (it returns 0.0.0.0 as the IP address instead of the real address)
It does no harm but it's certainly annoying.
There are at least two solutions if pi-hole is the culprit:
Whitelist api.segment.io in pi-hole; use this command: pihole -w api.segment.io
Tell ddev not to send instrumentation messages via segment: ddev config global --instrumentation-opt-in=false
Hi have a slightly different error message:
segment 2020/08/17 09:39:08 ERROR: sending request - Post "https://api.segment.io/v1/batch": x509: certificate is valid for *.ddev.local, *.ddev.site, localhost, ddev-router, ddev-router.ddev_default, not api.segment.io
segment 2020/08/17 09:39:08 ERROR: 2 messages dropped because they failed to be sent and the client was closed
But it has the same reason: pi-hole is blocking segment.io.
I can find the blocked requests in the pi-hole log (pihole -t). And I found the domains segment.io and segment.com in one of the pi-hole default blocklists on GitHub. This list is genereated automatically and the segment.io entry comes from adaway.org. Seems like the lines where added ~8 month ago.
Like described in this answer it helps to whitlist segment.io in pi-hole or disable the reporting feature in ddev.
I tried to connect to the Push API in poloniex using python and followed the instructions on the answer here:
How to connect to poloniex.com websocket api using a python library
However I keep getting this error:
2017-06-25T04:07:04 dropping connection to peer tcp:104.20.13.48:443 with abort=True: WebSocket opening handshake timeout (peer did not finish the opening handshake in time)
Anyone know what's going on here? I can't figure it out from online documentation. Thanks!
As per #Cyphrags suggestion, I was able to get my autobahn websocket to work outside of localhost by increasing openHandshakeTimeout with factory.setProtocolOptions
factory.protocol = MyClientProtocol
factory.setProtocolOptions(failByDrop=False, openHandshakeTimeout=90, closeHandshakeTimeout=5)
Solution found via https://github.com/crossbario/crossbar/issues/930. Perhaps the reason it is needed has something to do with slow DNS routing taking longer than the default handshake time.
I am working on a Windows (Microsoft Visual C++ 2005) application that uses several processes
running on different hosts in an intranet.
Processes communicate with each other using TCP/IP. Different processes can be on the
same host or on different hosts (i.e. the communication can be both within the same
host or between different hosts).
We have currently a bug that appears irregularly. The communication seems to work
for a while, then it stops working. Then it works again for some time.
When the communication does not work, we get an error (apparently while a process
was trying to send data). The call looks like this:
send(socket, (char *) data, (int) data_size, 0);
By inspecting the error code we get from
WSAGetLastError()
we see that it is an error 10054. Here is what I found in the Microsoft documentation
(see here):
WSAECONNRESET
10054
Connection reset by peer.
An existing connection was forcibly closed by the remote host. This normally
results if the peer application on the remote host is suddenly stopped, the
host is rebooted, the host or remote network interface is disabled, or the
remote host uses a hard close (see setsockopt for more information on the
SO_LINGER option on the remote socket). This error may also result if a
connection was broken due to keep-alive activity detecting a failure while
one or more operations are in progress. Operations that were in progress
fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.
So, as far as I understand, the connection was interrupted by the receiving process.
In some cases this error is (AFAIK) correct: one process has terminated and
is therefore not reachable. In other cases both the sender and receiver are running
and logging activity, but they cannot communicate due to the above error (the error
is reported in the logs).
My questions.
What does the SO_LINGER option mean?
What is a keep-alive activity and how can it break a connection?
How is it possible to avoid this problem or recover from it?
Regarding the last question. The first solution we tried (actually, it is rather a
workaround) was resending the message when the error occurs. Unfortunately, the
same error occurs over and over again for a while (a few minutes). So this is not
a solution.
At the moment we do not understand if we have a software problem or a configuration
issue: maybe we should check something in the windows registry?
One hypothesis was that the OS runs out of ephemeral ports (in case connections are
closed but ports are not released because of TcpTimedWaitDelay), but by analyzing
this issue we think that there should be plenty of them: the problem occurs even
if messages are not sent too frequently between processes. However, we still are not
100% sure that we can exclude this: can ephemeral ports get lost in some way (???)
Another detail that might help is that sending and receiving occurs in each process
concurrently in separate threads: are there any shared data structures in the
TCP/IP libraries that might get corrupted?
What is also very strange is that the problem occurs irregularly: communication works
OK for a few minutes, then it does not work for a few minutes, then it works again.
Thank you for any ideas and suggestions.
EDIT
Thanks for the hints confirming that the only possible explanation was a connection closed error. By further analysis of the problem, we found out that the server-side process of the connection had crashed / had been terminated and had been restarted. So there was a new server process running and listening on the correct port, but the client had not detected this and was still trying to use the old connection. We now have a mechanism to detect such situations and reset the connection on the client side.
That error means that the connection was closed by the
remote site. So you cannot do anything on your programm except to accept that the connection is broken.
I was facing this problem for some days recently and found out that Adobe Acrobat Reader update was the culprit. As soon as you completely uninstall Adobe from the system everything returns back to normal.
I spent a long time debugging a 10054/10053 error in s3 pre-signed uploads
Turns out that the s3 server will reject pre-signed s3 uploads for the first 15 minutes of it's life.
So - If you're debugging s3 check it's not a new bucket.
If you're debugging something else - this is most likely a problem on the server side not client side.