I recently upgraded and updated my Mosquitto Broker to 1.4.15 on Raspberry-pi3. It works as expected. However, every time I enable and set cleansession to true in the Mosquitto.Conf file, Mosquitto broker refuses to start. As soon as I comment out or disable cleansession, Mosquitto broker starts up immediately by its service. The reason I need to set this to true is because I want the Mosquitto Broker to clean up any disconnected clients' session. So that the same client can reconnect again to the broker. Am I doing this right? or Is there another Mosquitto Broker's feature that I can use in place of cleansession?
The cleansession flag in the mosquitto.conf is to control what options mosquitto uses when it connects to remote brokers as a client when setting up a bridge.
If you want your clients to connect with a clean session then you need to set that option in your client library when setting up the connection not on the broker.
Related
I am working on a MQTT project using local mosquitto broker.
Currently for testing, I want my broker to require authentication even from same machine clients. But it looks like the broker is allowing them even if they don't have the username or the password.
my mosquitto.conf:
allow_anonymous true
password_file C:\Documents\...\password_file.txt
For Mosquitto v2.0.x and newer just remove the allow_anonymous true or set it to false (for previous versions)
When set to true mosquitto will allow clients to connect without a username or password.
Writing this for others who may be in the same situation as I was.
mosquitto.exe -v -c mosquitto.conf
solved the problem.
I am running mosquitto on a raspberry pi and it all functions fine with an ethernet connection. I have two listeners, one limited to localhost for most of the functionality and another limited to the vpn ip address so that I can do some administration over vpn, all others are then excluded. The problem is that once this device goes out into the world it may or may not have an internet connection, but if the internet connection is not there, the vpn address does not exist and mosquitto fails to start.
I am using mosquitto v2.0.4, but I can update if required.
Does anyone have any suggestions on how I can solve this?
per_listener_settings true
retain_available true
log_dest stdout
listener 1883 localhost
allow_anonymous true
listener 1886 10.8.0.100
max_connections 1
allow_anonymous true
No, if you specify a listener for a non existent IP address then mosquitto will fail to start.
The solution is probably to specify a listener without an IP address (so it will bind to 0.0.0.0 and be available on all listeners) and rely on suitable authentication to limit access rather than the connection arriving on a specific interface.
If really needed you can use the firewall on the device to filter connections to that port to only be allowed from a specific subnet that matches that configured for the VPN.
I hosted Mosquitto MQTT broker on Ubuntu in Digital Ocean Cloud droplet. It's domain name is instrux.live and IP of the domain is 192.34.63.138. I publish and subscribe messages from two terminal windows and it worked fine.
When I tried to connect it with the android using Paho MQTT android client it could not connect. I also checked its connection with the MyMQTT android application and it did not connect. After making sure the android code has not any error, I again checked its connection with the Eclipse Paho Javascript client on eclipse.org website and it did not connect. Now, I have realized there might be something missing or wrong in my broker configuration which is not allowing it to get connected with other clients remotely. I have also opened firewall for ports 1883 for Android client and 8083 for the Javascript client and still it is not connecting.Here is mosquitto configuration file:
allow_anonymous true
password_file /etc/mosquitto/passwd
listener 1883
protocol mqtt
listener 8083
protocol websockets
Since the error is "Connection Refused" rather than a timeout I suspect that you have not configured the firewall to allow inbound traffic on port 8083.
You may need to do this both on the machine it's self and in Digital Ocean's console.
I have one remote broker (cloudmqtt) and one local broker on my board. Both are connected as bridge. I have one paho client connected to local broker. I want to know the status of bridge in order to publish message. I know I can publish message to local broker without knowing status and broker will take care. But I want to design my application like I will Publish message only if bridge is Up.
I am using paho client library in C and mosquitto broker v1.6.
Below is my conifg file :
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
log_timestamp true
log_timestamp_format %Y-%m-%dT%H:%M:%S
log_type all
user root
connection cloudmqtt
address xxxx.cloudmqtt.com:13287
remote_username xxxxxxx
start_type automatic
try_private true
remote_password xxxxxx
notifications true
notification_topic /broker/connection/state
restart_timeout 20
max_queued_messages 0
topic # both 2
The short answer is you can't at a pure MQTT protocol level or specific to the Paho client (and you shouldn't care for the reasons you mentioned).
Now having said all that you can actually get messages about the bridge status from the $SYS/broker/connection/<remote-clientid>/# topic tree on mosquitto. To enable this you need to set the notification true flag in the bridge config. The doc for configuring bridges is here
I have a scenario wherein the MQTT client publishes a message with a topic . Post this I bring down my mosquitto broker (by killing the process) . When I restart my broker and try consuming the message with the topic , the message is not available . Is there any way I can consume the message which was published before the broker is restarted ?
Note : This is possible if RabbitMQ is used as the messages are stored in the queue . I want to implement the same using MQTT-Mosquitto.
If you enable persistence and specify a directory in your mosquitto.conf file then retained messages will be saved to disk and restored when the broker is restarted.
e.g.
persistence true
persistence_location /path/to/store/data/
Also look at the autosave_interval and autosave_on_changes options in the docs