I am unable to connect to socketcluster server from Firefox and chrome for android. Is there any solution?
The 'Socket hung up' error can mean either: The server was disconnected abruptly (e.g. the connection was lost for whatever reason). OR the client could not find the target server while trying to connect - It could be because the wrong arguments were passed to the client (E.g. don't match the server host, port, ...) or a network connection issue.
Are you trying to connect over 3G? Some 3G ISPs and some corporate networks block raw WebSocket traffic. If that's the case, the solution is to serve SocketCluster over wss:// - Proxies won't be able to block it if the connection is encrypted.
To make it work, you just need to provide a TLS key and certificate to the main SocketCluster constructor. Or you can put the raw SC server behind a TLS-enabled load balancer like AWS CloudFront, CloudFlare or similar (make sure it supports proxying WebSocket traffic).
Related
I am running an eth node (prysm) on an ec2 which the api data is accessible through port 3500. I have made the ec2 inbound security traffic publicly accessible to all traffic to query the api from anywhere.
However, the api seems to be only accessible internally through 0.0.0.0:3500, whenever I am trying to access the api publicly through the ec2 ipv4 address (e.g http://3.10.45.65:3500/eth/v1alpha1/beacon/chainhead <-dummy link) i ran into the error ConnectionRefusedError: [WinError 10061] No connection could be made because the target machine actively refused it.
Just to make sure the ec2 was configured well, I hosted a dummy page publicly using python http server through port 3500 which was functioning well and was publicly accessible.
I am a lil confused to what else could be blocking the server from handling the request.
Any input would be appreciated.
I ended up using a reverse proxy server such as caddy (https://caddyserver.com/docs/quick-starts/reverse-proxy) which redirected the queries back to the localhost and it worked. Nevertheless, try to keep your ip private
I would like to seek for your advice if you have any idea or you have already encountered this issue “SSL/TLS handshake Issue” ?
To give you a summary, we’re getting an error the error below when connecting to Coupa (ERP) through HTTP.
Remote host closed connection. Possible SSL/TLS handshake issue. Check protocols, cipher suites and certificate set up. Use -Djavax.net.debug=ssl for further debugging.
We have several HTTP requests using the same HTTP config, but there’s this only one specific request that gives the said error. Also, this HTTP request works in postman. This occurs only in one Mule environment (UAT Environment). It works fine in our sandbox environment.
We are not sure whether the SSL connection/Handshake is closed on our end or server end.
If ever its on our end, how do we identify the fix for that?
If it’s on the server end, what should be the proof that we need to provide to them to say that the issue is on their end.
The server -Coupa in this case- is closing the connection just after it was opened by the client -a Mule application- probably before the client can send the HTTP request. The server could do this by any of a number of causes and the client does not receive any error messages or codes to indicate a reason. You will need to learn the reason from the server side.
Usual reasons are because an HTTPS connection doesn't match thee required ciphers suites or protocol versions accepted by the server, or because the client IP is not whitelisted. In those situations documentation from what's acceptable to the server side is useful. There could some other reasons that are known only to the server side.
A method to troubleshoot TLS connection issues is to do a traffic capture of the TCP packets, ideally from both sides, but if you don't control the server it will be only possible from the client. Another option if you are using HTTPS is to enable Java SSL Debug log in the Mule runtime to print the HTTPS connection information. You need to understand how to troubleshoot TLS to use these tools.
I am trying to view the messages and communication of an SSL WebSocket server and client. The client is written in Java, so I could technically view the code with something like Recaf or JD-GUI, but I do not have access to the WS server. Is there any program that I could use to intercept the traffic of the client and server (Note: I am able to change the host, port, and protocol of the client's WS connection (like change it to ws://localhost:8080 from wss://server:port/path)).
Is there any program that can act as a non SSL WebSocket server, and then forward all connections to the remote server while logging the messages?
I have configured the Websocket on my live server and I'm using SSL on live server. When I used following code on my localhost, websockets were fine.
ws://localhost:8080/server.php
Once I moved the file to the live server I have changed the code to the following
wss://IP:PORT/server.php
I have created a seperate port for web socket and configured on firewall TCP IN and OUT. However, I'm receiving the following error on console
WebSocket connection to ............ failed: Error in connection establishment: net::ERR_SSL_PROTOCOL_ERROR
Can anyone suggest me some solutions to overcome this issue
Basically when you are using wss you are just serving the WebWocket over SSL/TLS.
Meanwhile using a simple ws does not require a particular setup, wss does. Indeed you have to create a secure connection using a valid SSL Certificate when opening the communication.
If you certificate is missing or invalid the connection cannot be enstabilished therefore an error will be raised while attempting to start the communication.
So you can't just switch from ws to wss but also have to make a proper implementation.
You can find more details here, hope that helps!
here is what I did, I never able to install ssl in local, so I started using the w3cwebsocket client
https://www.npmjs.com/package/websocket
and test it in console using
node index.js
var W3CWebSocket = require('websocket').w3cwebsocket; var client =
new W3CWebSocket('wss://127.0.0.1:7000/'); console.log(client)
I followed the instructions from this link:
How do you get Amazon's ELB with HTTPS/SSL to work with Web Sockets? to set up ELB to work with Websocket (having ELB forward 443 to 8443 on TCP mode). Now I am seeing this issue for wss: server sends message1, client does not receive it; after few seconds, server sends message2, client receives both messages (both messages are around 30 bytes). I can reproduce the issue fairly easily. If I set up port forwarding with iptable on the server and have client connecting directly to the server (port 443), I don't have the problem Also, the issue seems to happen only to wss. ws works fine.
The server is running jetty8.
I checked EC2 forums and did not really find anything. I am wondering if anyone has seen the same issue.
Thanks
From what you describe, this pretty likely is a buffering issue with ELB. Quick research suggests that this actually is the issue.
From the ELB docs:
When you use TCP for both front-end and back-end connections, your
load balancer will forward the request to the back-end instances
without modification to the headers. This configuration will also not
insert cookies for session stickiness or the X-Forwarded-* headers.
When you use HTTP (layer 7) for both front-end and back-end
connections, your load balancer parses the headers in the request and
terminates the connection before re-sending the request to the
registered instance(s). This is the default configuration provided by
Elastic Load Balancing.
From the AWS forums:
I believe this is HTTP/HTTPS specific but not configurable but can't
say I'm sure. You may want to try to use the ELB in just plain TCP
mode on port 80 which I believe will just pass the traffic to the
client and vice versa without buffering.
Can you try to make more measurements and see how this delay depends on the message size?
Now, I am not entirely sure what you already did and what failed and what did not fail. From the docs and the forum post, however, the solution seems to be using the TCP/SSL (Layer 4) ELB type for both, front-end and back-end.
This resonates with "Nagle's algorithm" ... the TCP stack could be configured to bundling requests before sending them over the wire to reduce traffic. This would explain the symptoms, but worth a try