I am having some problems with my Mosquitto MQTT broker which I do not understand. I had setup another Mosquitto broker in a Google Cloud Ubuntu 20.04 VM and it was working properly. I have moved to a self-managed Ubuntu 20.04 VM in my university and have not been able to connect to the broker ever since. A little background on the current setup:
netfilter-persistent firewall (am unsure of the exact name of the firewall, this is the name of th service) has port 1883 open
ufw is inactive
the university has 2 levels in the firewall, one in the VM and one external. I have asked for the opening of ports 1883 (I am aware that only port 8883 should be open but this is temporary until I solve my issue)
the VM is accessible from outside the LAN of the university, as checked in https://www.yougetsignal.com/tools/open-ports/
I have an Apache webpage running and it is also accessible externally
I have NodeRED using port 1880 and it is also accessible externally
My Mosquitto conf file looks like the following. For the time being, I am not using TLS authentication, as I first need to solve the issue with the connection.
allow_anonymous false
password_file /etc/mosquitto/passwd
listener 1883 0.0.0.0
However, I have not been able to enable the communication when using either the server IP or the domain name. If I attempt to connect using localhost, everything works:
~$ mosquitto_sub -h localhost -t test -p 1883 -u "XX" -P "XX" -d
Client (null) sending CONNECT
Client (null) received CONNACK (0)
Client (null) sending SUBSCRIBE (Mid: 1, Topic: test, QoS: 0, Options: 0x00)
Client (null) received SUBACK
Subscribed (mid: 1): 0
If I attempt to connect with the domain name, I never receive an acknowledgment and the connection is never established:
~$ mosquitto_sub -h domain.com -t test -p 1883 -u "XX" -P "XX" -d
Client (null) sending CONNECT
Client (null) sending CONNECT
Client (null) sending CONNECT
Client (null) sending CONNECT
Client (null) sending CONNECT
Mosquitto seems to be properly bound when running the lsof -i command in the console:
mosquitto 2177304 mosquitto 5u IPv4 10127120 0t0 TCP *:1883 (LISTEN)
mosquitto 2177304 mosquitto 7u IPv4 10127251 0t0 TCP localhost:1883->localhost:47236 (ESTABLISHED)
I would appreciate it if anyone could guide me into what could be the root of my issue. If more information is needed regarding my setup, I will gladly provide it.
Thanks in advance to all!
Related
in localhost, my broker works great, but when I use broker IP on another device to connect over the internet that's not work,
Websocket is fine
I use this command to subscribe on topic and get the retained messages
mosquitto_sub -h *.*.*.* -p 1883 -t mrt_connections/#
in localhost and when I used VPN I get current information, but when I use broker IP to use with another device over the internet I can't get any data
this log when I used Ip over the internet
1673794013: New connection from ****.****.***.**** on port 1883.
1673794013: New client connected from ****.****.***.**** as auto-48259EF8-9CF7-9CF5-3C2C-20FA8265C33A (p2, c1, k60).
1673794013: No will message specified.
1673794013: Sending CONNACK to auto-48259EF8-9CF7-9CF5-3C2C-20FA8265C33A (0, 0)
1673794017: New connection from *.*.*.* on port 1883.
I guessed that maybe port 1883 is blocked by ISP but another broker with the same port working, I test many IP but the problem is still alive,
can anybody explain to me what is a problem
thanks
I used version 2.0.15
config file
allow_anonymous true
listener 1883 *.*.*.*
log_type all
log_dest topic
log_dest stdout
Finally, I found the problem, the port was blocked by ISP and now MQTT works fine on port 443
I am running Mosquitto MQTT broker on the localhost of my PC and I want to publish or subscribe data through MQTT with Mosquitto from a remote IP (another PC). Both the PCs are connect to the same Wifi public network. I have disable the firewall of the two PCs and I am able to ping one another on command prompt. I have look up on several websites and tried editing the config file of the Mosquitto MQTT broker by adding these two lines.
listener 1883
allow_anonymous true
I have started the Mosquitto broker by executing mosquitto -c mosquitto.conf -v
The following is the log appear the mosquitto start.
C:\Program Files\mosquitto>mosquitto -c mosquitto.conf -v
1665133477: mosquitto version 2.0.15 starting
1665133477: Config loaded from mosquitto.conf.
1665133477: Opening ipv6 listen socket on port 1883.
1665133477: Opening ipv4 listen socket on port 1883.
1665133477: mosquitto version 2.0.15 running
However, on the publishing PC, it prompts the error below.
C:\Program Files\mosquitto>mosquitto_pub -h XXX.XXX.XX.X -t Test -m "Hello World" -p 8883 -d
Error: No connection could be made because the target machine actively refused it.
The situation is same for subscribing. I am currently using the latest version of Mosquitto 2.0.15. Can anyone help me on this situation? Your help would be much appreciated. Thanks in advance!
I am running Mosquitto 1.4.8 on Ubuntu successfully on port 1883 (tested from another machine with mosquitto_sub/mosquitto_pub). However I am encountering issues when attempting to use another port eg.
mosquitto -p 1884 -c moddebug.conf
This works OK if I access it from the same machine e.g.:
mosquitto_pub -h 127.0.0.1 -p 1884
but if I attempt to connect from another machine I get an error:
mosquitto_pub -h IP_ADDRESS -t exmapleTopic -p 1884
Connection timed out
My moddebug.conf file is:
log_type all
log_dest file mosquitto2_log.log
The log does not provide any extra information:
Config loaded from mosdebug.conf.
Opening ipv4 listen socket on port 1884.
Opening ipv6 listen socket on port 1884.
mosquitto version 1.4.8 terminating
I have tried altering the firewall rules (but this did not help):
ufw allow 1884/tcp
Rules updated
Rules updated (v6)
When I publish and subscribe at localhost its work fine.
When I try from my PC at home I just can't connect to the broker.
open TCP port in/out at security group - 1883 8883 8080
open the ports also at my ec2 instance firewall...
what is the problem? I use the public DNS by amazon as I think I should...
This is an exercise at diagnosing network problems:
1) netstat -a -n | grep 1883
will tell you whether your broker is configured correctly
2) wireshark packet capture will tell you whether your system is receiving packets at the specific port
You will not get an answer until you at least do those.
I have installed Mosquitto on a brand new Raspberry Pi. OS is Raspbian.
I followed the instructions on the Owntracks website.
The broker is listening on port 1883 on localhost. Using a username and password I can run mosquitto_sub in one ssh session to the Pi, and receive messages sent by mosquitto_pub from another ssh session.
The broker is also listening on port 8883. I created certificates using the script in the Owntracks repository.
When I run mosquitto_pub on the Pi, using the hostname or IP-address I get an error "Error: Connection refused".
When I use localhost or 127.0.0.1 the error is "A TLS error occurred.".
If I run mosquitto_pub on my desktop computer (which is in the same LAN as the Pi), the error is "Connection refused". The command I run here is
mosquitto_pub -t owntracks/test -m Test -h pi1 --cafile ca.crt
where pi1 is the hostname of the Pi running the broker. The ca.crt file is copied from the Pi to the desktop computer.
The Mosquitto log is not showing why the connections are refused.
The TLS setup in the Mosquitto config looks like this:
listener 1883 127.0.0.1
listener 8883
cafile /etc/mosquitto/ca_certificates/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key
require_certificate false
What is wrong in my setup?
if you try to use TLS with mosquitto
you must add this option to your command "-p 8883" to indicate the port
and you don't need to put "-h localhost or pi " because you use the client command mosquitto_pub in the same machine that run mosquitto broker
then your command we'll be :
"mosquitto_pub -d -u username -P password -t /path/to/the/topic --cafile /path/to/the/certificate -p 8883
don't forgot to comment this line
listener 1883
in your mosquitto.conf
Recreating all certificates solved the problem. Apparently I did something wrong with including local vs. remote IP-addresses and host names.
The TLS error messages are not very informative, but that probably has to do with security precautions.