I have a Netty 3 client over HTTPS.
I can't puzzle out why it's not working and just hangs until timeout.
It works perfectly fine over HTTP (remove the SSL handler from the pipeline and change port from 443 to 80).
Here's a gist (in scala): https://gist.github.com/4396611
What am I doing wrong?
I've tested with Netty from 3.5.9 to 3.6.0.
My JDK is 1.6.0_37 on OS X.
Regards,
Stéphane
You missed to issue the handshake once the channel is connected. The easiest way is to use setIssueHandshake on the SslHandler before add it to the pipeline.
http://static.netty.io/3.6/api/org/jboss/netty/handler/ssl/SslHandler.html#setIssueHandshake(boolean)
Related
I have a Mosquitto 2.0.14 broker running in a Windows server 2019. I can connect to it over port 8883 using mqtts protocol with SSL enabled. I can also connect to it on port 1883 without SSL.
Now I want to connect using Websockets. So I added a listener as:
listener 9001
protocol websockets
allow_anonymous false
password_file C:\mosquitto\password.txt
http_dir C:\mosquitto\http_dir
set_tcp_nodelay true
I also tried without http_dir and set_tcp_nodelay. I have tried with and without SSL certificates.
I have port 9001 opened in windows firewall as well as on AWS EC2 instance security groups.
But when I try to connect to the broker using ws://broker.mysite.com:9001 or ws://broker.mysite.com:9001/mqtt nothing happens. No error, no connection. Mosquitto does not show any logs even though I can see the request coming in using WireShark. I am really stuck here. please help me out.
Edit:
I have tried to connect using MQTTX, MQTT Explorer and MQTTBox Chrome App.
As per the comments this issue has been noted previously (in this answer), however I figure its worth repeating here to aid others who experience the problem.
In short - there appears to be a bug in Mosquitto versions 2.0.12, 2.0.13 & 2.0.14 running on Windows when listening for websocket connections. Whilst the broker appears to be listening (on the correct port) it does not, in fact, accept connections (and nothing is logged). I have not investigated in detail but the cause is going to be something about the way the socket is being configured.
There is a workaround - add socket_domain ipv4 under the listener e.g.
listener 9001
protocol websockets
allow_anonymous false
password_file C:\mosquitto\password.txt
http_dir C:\mosquitto\http_dir
set_tcp_nodelay true
socket_domain ipv4
See this issue in the github repo for more information.
I am trying to start my Eclipse Mosquitto broker service for listening to websockets adding:
listener 8083
protocol websockets
at the mosquitto.conf
If I only use listener 8083, the service starts but when protocol websockets is added, the service stops and refuses to start.
The error I get if I run:
mosquitto -v -c mosquitto.conf
is: 1588309602: Error: Unable to start any listening sockets, exiting.
The full output is:
1588309602: mosquitto version 1.6.9 starting
1588309602: Config loaded from mosquitto.conf.
1588309602: Opening websockets listen socket on port 8083.
1588309602: Error: Unable to start any listening sockets, exiting.
I am under Windows10 Pro.
Any ideas?
The answer to this:
Based on trials I can confirm that you need to mention a default port initially e.g.
port 1883
protocol mqtt
# Websockets
listener 9001
protocol websockets
if you only wish to use WebSockets for MQTT then instead of using listener 9001 you need to replace it with port 9001.
There should be atleast one default port to listen to in Mosquitto MQTT.
Verified using Mosquitto 1.6.10
I am posting an answer based on facts.
I have uninstalled version 1.6.9 and installed 1.6.7 and now the service is running using websockets...
I cannot confirm if this is an issue with 1.6.9 but this is what happened to me.
BR
According to other sources, the error lies in 1.6.10 (and perhaps others), whereby, there MUST be a standard protocol mqtt defined, otherwise websockets will not start.
Thus you can leave the standard configuration alone (port 1883) and then in the
Extra listeners section of mosquitto.conf, define the websockets listener as you like.
I believe this has been remedied in later versions, so that only websockets can be defined.
Sadly, in this case the only defense against unauthorized use of the broker over the standard mqtt socket is then the system firewall for external users. Users with ssh access can "play".
The mqtt protocol has to be enabled for the websockets to work.
As the option port (like others have mentioned) is deprecated in versions 2.x.x, you can use listener instead.
listener 1883
protocol mqtt
listener 9001
protocol websockets
And then run your mosquitto server as usual.
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.
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 have a web page to control a thermostat on a raspberry pi, and I'm running into difficulties when trying to get websockets to work from a remote client. It seems to work fine when on LAN however. I'm obviously missing something (and likely something basic), but I can't seem to figure out what it is.
The pi's local ip is 192.168.1.134. The web page (served from apache server) has the URL http://192.168.1.134:8010/thermostat.html. The page starts up some javascript, which then tries to connect to the pi's main program using websockets via ws://192.168.1.134:9000. (the server on the pi is running libwebsockets). The websocket comes up, and it seems to work fine. I then tried to connect via a remote client (a cell phone, where wifi was turned off) from http:\\23.239.99.99:8010\thermostat.html. The html/js files load fine, but the web socket attempts to connect to uri ws:\\23.239.99.99:9000, and this fials.
As far as I can tell, the NAT seems to be configured properly:
name ext ext protocol int int ip addr interface
port port port port
start end start end
Thermostat3 8010 8010 TCP 8010 8010 192.168.1.134 eth3.1
Thermostat5 8000 8000 TCP/UDP 80 80 192.168.1.134 eth3.1
Thermostat_ws 9000 9000 TCP/UDP 9000 9000 192.168.1.134 eth3.1
I checked, and the router does not have any firewalls set up, neither does my modem. I didn't install a firewall on the pi (I checked, and there's no odd iptables rule). Does anyone know what I'm missing?
--- EDIT ---
I'm still stuck on this. I called my ISP and they assure me there are no firewalls on their servers. Is there any way to tell if port 9000 is being blocked, and by who?
Bind your apache server to 0.0.0.0 address to make it accessible from remote machines
Try this tool to determine if the port is inaccessible (use the custom port): http://www.whatsmyip.org/port-scanner/
Everything else looks fine. As a sanity check I would try putting the ws port to 8010 to see if that works. I would also recommend using a tool like Advanced Web Client to isolate networking issues.
This is interesting. I once had a similar problem. I set up a WebSocket (I was using a nodejs ws) and once I tried to access it from remote client I was not able to reach it with ws://yourip:port but instead I had to use http://yourip:port. I don't know if you have the same problem, mine was due to a proxy I was using.
I still have an advice for you how you might be able to solve your problem. I don't know how concerned you are about security but as far as I understood your idea you basically connect to your raspberry pi through a WebSocket and tell it to change the temperature.
Back when did a similar project I found it rather hard to secure my WebSocket connection. I was basically sending a password plus command through the WebSocket to my server which then checks wether the password is correct. Otherwise everyone on the internet could heat your house. Not cool...
But therefore, I had to tunnel the connection through https to prevent a middleware attack.
I quickly threw the towel and decided to go with a completely different solution. Basically I set up a nodejs express server (can easily be configured with a self signed certificate to use https or used behind a nginx/apache https server) and authenticated with username and password. When someone made a POST request to /api/thermostats?id=0 with a temperature request, the server checks if the user is authenticated and then executes a terminal command from within node.
Maybe this idea also fits your demands.