today I wanted to set up a simple mosquitto server on my windows machine for testing.
I am using "MQTT Explorer" for convenience and downloaded the latest 2.0.14 mosquitto binaries for windows (I am using Windows 10).
However I am unable to connect to my local server with Mosquitto 2.0.14, 2.0.13 and 2.0.12.
My connection is successful with 2.0.11, 2.0.10, 2.0.9a and 2.0.7 but these versions only work when I also have a standard http listener in the config (which I do not want since later on I only want one wss listener).
This is the config I am using:
allow_anonymous true
#HTTP listener
listener 1883
#Websocket standard listener
listener 9001
protocol websockets
This is the server output I get when using 2.0.14, 2.0.13 or 2.0.12 after my connection failed:
And this is the output when using 2.0.11, 2.0.10, 2.0.9a or 2.0.7 but without the http listener in the config:
Can anyone reproduce this behaviour or tell me where I messed up?
As per the comments I was able to duplicate the issue with Mosquitto 2.0.14 and an issue has been raised.
A workaround is to add socket_domain ipv4 into the configuration - e.g.
allow_anonymous true
listener 9001
protocol websockets
socket_domain ipv4
I came across option in this issue and it does appear to fix the issue. Note that I have not looked into why this fixes the issue so this should be considered a temporary workaround until the issue mentioned above is updated.
Related
I have recently upgraded to 1.6.6.1 version of SuperSocket.Common, SuperSocket.SocketBase, SuperSocket.SocketEngine and SuperSocket.WebSocket. Everything works fine except it does not work when the client is using https to connect to my Web service.
Both http & https work fine with the older version of SuperSocket dlls and SuperWebSocket dll.
Has anyone used 1.6.6.1 versions of SuperSocket.Common, SuperSocket.SocketBase, SuperSocket.SocketEngine and SuperSocket.WebSocket with Https?
When I look at the logs I see that session was connected and then was closed by the client after few secs. When I attach the debugger it seems to call only the CloseSession handler but does not call the SessionConnect and SessionMessageReceive handlers in my code. It throws no exception or any other error log.
Does this require TLS 1.2 to be enabled to work? or any new config for tls for SuperSocket.WebSocket?
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.
OF version:3.9.1, I can use pidgin to log on.
When using strophe.js, I tried BOSH first, but it fails, probably I didn't get apache settings right. Then I decide to try websockets, and this is my preferred option, however, I got the following error message:
WebSocket connection to 'ws://ikan.tk:7070/ws/server' failed: WebSocket is closed before the connection is established.
then the status is "connecting" always.
Questions:
what's the URL for websocket? using http-bind port (7070), or the client port (5222)? Any path (like /ws/server) to be followed ?
I'm using OF 3.9.1 on windows, no plugin installed. Does OF 3.9.1 support WS by default, or I have to install some plugin, or there's some configuration items I need to do?
Thanks in advance!
AFAIK,
1) The URL for websocket on OpenFire is ws://of-server:7070/ws with default configuration (see below).
2) You need to install the "WebSockets Plugin" plugin for OpenFire, then you can configure the path of the websocket ("ws" is default) in properties page under the "Server > WebSockets" tab.
I am trying to install the IPython html notebook server
on dotCloud. The IPython server uses tornado with websockets (and other internal communications using zeromq on tcp sockets).
Hhere's my dotcloud.yml:
www:
type: custom
buildscript: builder
ports:
nbserver: tcp
I am following the custom port recipes given here and here. As the logs show, I run the tornado server on 127.0.0.1:$DOTCLOUD_WWW_NBSERVER_PORT:
/var/log/supervisor/www.log:
[NotebookApp] The IPython Notebook is running at: 'http://127.0.0.1:35928/'
[NotebookApp] Use Control-C to stop this server and shut down all kernels.
But when I push, the dotCloud CLI tells me:
WARNING: The service crashed at startup or is listening to the wrong port. It failed to >respond on port "nbserver" (42801) within 30 seconds. Please check the application logs.
...
Deployment finished. Your application is available at the following URLs
No URL found. That's ok, it means that your application does not include a webservice."
There's nothing on my-app.dotcloud.com or my-app.dotcloud.com:DOTCLOUD_WWW_NBSERVER_PORT
What am I missing here? Thanks for your help.
UPDATE
Issue solved. The usual HTTP port works fine with websockets so the custom port recipes are not required. This is my new dotcloud.yml:
www:
type: custom
buildscript: builder
ports:
web: http
works with the following in ipython_notebook_config.py:
c.NotebookApp.ip = '*'
This makes it so that the tornado webserver listens to all ip addresses.
WARNING: setup security and authentication first!
See Running a Public Notebook Server for more information.
Glad you got it working!
In the future, and for other readers, you actually want your app to listen on $PORT_NBSERVER and then connect to it on DOTCLOUD_WWW_NBSERVER_PORT. $PORT_NBSERVER is the local port while the latter is the port that's exposed to the outside world through our routing/NAT layer.
If you have any other issue, don't hesitate to reach out to us at http://support.dotcloud.com
Source: I'm a dotCloud employee.