I have a virtual machine that is supposed to be the host, which can receive and send data. The first picture is the error that I'm getting on my main machine (from which I'm trying to send data from). The second picture is the mosquitto log on my virtual machine. Also I'm using the default config, which as far as I know can't cause these problems, at least from what I have seen from other examples. I have very little understanding on how all of this works, so any help is appreciated.
What I have tried on the host machine:
Disabling Windows defender
Adding firewall rules for "mosquitto.exe"
Installing mosquitto on a linux machine
Starting with the release of Mosquitto version 2.0.0 (you are running v2.0.2) the default config will only bind to localhost as a move to a more secure default posture.
If you want to be able to access the broker from other machines you will need to explicitly edit the config files to either add a new listener that binds to the external IP address (or 0.0.0.0) or add a bind entry for the default listener.
By default it will also only allow anonymous connections (without username/password) from localhost, to allow anonymous from remote add:
allow_anonymous true
More details can be found in the 2.0 release notes here
You have to run with
mosquitto -c mosquitto.conf
mosquitto.conf, which exists in the folder same with execution file exists (C:\Program Files\mosquitto etc.), have to include following line.
listener 1883 ip_address_of_the_machine(192.168.1.1 etc.)
By default, the Mosquitto broker will only accept connections from clients on the local machine (the server hosting the broker).
Therefore, a custom configuration needs to be used with your instance of Mosquitto in order to accept connections from remote clients.
On your Windows machine, run a text editor as administrator and paste the following text:
listener 1883
allow_anonymous true
This creates a listener on port 1883 and allows anonymous connections. By default the number of connections is infinite. Save the file to "C:\Program Files\Mosquitto" using a file name with the ".conf" extension such as "your_conf_file.conf".
Open a terminal window and navigate to the mosquitto directory. Run the following command:
mosquitto -v -c your_conf_file.conf
where
-c : specify the broker config file.
-v : verbose mode - enable all logging types. This overrides
any logging options given in the config file.
I found I had to add, not only bind_address ip_address but also had to set allow_anonymous true before devices could connect successfully to MQTT. Of course I understand that a better option would be to set user and password on each device. But that's a next step after everything actually works in the minimum configuration.
For those who use mosquitto with homebrew on Mac.
Adding these two lines to /opt/homebrew/Cellar/mosquitto/2.0.15/etc/mosquitto/mosquitto.conf fixed my issue.
allow_anonymous true
listener 1883
you can run it with the included 'no-auth' config file like so:
mosquitto -c /mosquitto-no-auth.conf
I had the same problem while running it inside docker container (generated with docker-compose).
In docker-compose.yml file this is done with:
command: mosquitto -c /mosquitto-no-auth.conf
Related
I am facing this issue for a couple of days and I am unable to reproduce it outside the Ubuntu Docker container.
Please refer to this simplified diagram of my architecture:
As you can see, I have everything running inside the Docker container.
This is not the typical issue of not being able to connect to inside the container, the whole application runs on the local network of the Docker container.
The Ubuntu Image is the official one with just some packages installed so that everything works (nothing too fancy, just python3 and some c++ tools).
It is running Mosquitto 2.0.15 with the following configuration:
listener 1883
protocol mqtt
allow_anonymous true
log_dest file /home/user/mosquitto.log
So, in summary, I am running an unsecured MQTT broker in the default port 1883. I also added a log file in an attempt to debug what is going on.
On my Python Client, the connection is made in the simplest way possible:
...
self.mqtt_client = mqtt.Client(client_id="Client Id")
self.mqtt_client.connect("localhost", 1883, 6000)
...
self.mqtt_client.loop_start()
...
This Client is able to connect to the broker with no issue at all.
Subscribe and Publish works perfectly too!
On my C++ Client, I try to keep it simple as well:
...
mqtt::async_client MQTTClient("tcp://localhost:1883", "Another Client Id");
MQTTClient.connect()->wait();
...
Yet, this Client fails every attempt to connect to the broker:
terminate called after throwing an instance of 'mqtt::exception'
what(): MQTT error [-1]: TCP/TLS connect failure
Aborted (core dumped)
Although it looks like a SSL/TLS error, this is actually the generic error for when the MQTT broker is not found (If I stop the broker on my local machine I get the same error).
Checking the MQTT broker logs (verbose ON), it does not record anything regarding the attempt to connect from C++ Client:
1672874968: mosquitto version 2.0.15 starting
1672874968: Config loaded from /etc/mosquitto/conf.d/default.conf.
1672874968: Opening ipv4 listen socket on port 1883.
1672874968: mosquitto version 2.0.15 running
(I do get log messages when connecting with Python Client)
On my own Linux machine I am unable to reproduce this issue. Both clients work fine.
I am using the same configuration for the Mosquitto broker and the Clients are exactly the same.
Already tried to play with the IP used to connect to the broker (localhost/127.0.0.1/0.0.0.0) and using different ports, the result is the same.
It is weird that the Python Client can connect with no issue at all.
At this point, I am fairly confident that the issue must be something Docker-specific and how it handles TCP sockets. But I am unable to find anything helpful online.
I can easily check that the port is open:
lsof -i -P -n | grep :1883
mosquitto 56 user 5u IPv4 1633274841 0t0 TCP 127.0.0.1:1883 (LISTEN)
Any ideas what is going on? Or debug tools ideas?
Thanks in advance!
I have tried:
Playing with IP and port of the broker;
Stating the preferable MQTT version (tried with every version);
Run Client with strace and try to find something unusual;
Verify if I am running the exact same Client as my Linux machine;
I finally found out what my issue was.
I had a HTTP proxy configured and Paho C will automatically use this proxy.
It is detecting by checking if "http_proxy" environment variable is set.
My solution was simply unset this variable:
unset http_proxy
Interestingly, the Python MQTT client does not have this behavior.
And for that reason, it worked perfectly!
I installed AzerothCore successfuly on Windows 10 Pro using Docker, and it works fine locally. I was trying to make the server public so friends can connect from the internet for testing.
Since port 8085 for worldserver can't be forwarded on my router (probably ISP or router firmware reserving it, other ports can just fine), I tried everything to change it in conf files, literally changed it everywhere and added the overrides in the 2 conf.dist. Changed it in the realmlist field in authserver DB too. Recompiled everything: it stays 8085 no matter what (I can see it using netstats).
In more detail: I changed the port to 8086 in \azerothcore-wotlk\docker\worldserver\etc\worldserver.conf.dist
added the line "WorldServerPort = 8086" in worldserver.conf and worldserver.conf.dockerdist in the same directory.
Even changed the port in .env.dist in main installation directory.
Also changed the relative field in the realmlist entry in authserver database.
I rebuilt all the containers from scratch after the config modifications and recomposed them: worldserver port stays 8085.
I managed to solve the problem with the help of Francesco Borzi: turned out dockers containers have their own ports exposed so I needed to change those too accordingly.
I edited the docker-compose.yml file in main directory, where ports for the world server container are listed, along with the usual editings of worldserver confs and authserver database entries as usual, and recomposed from scratch.
Thanks for help.
Remember you're using docker, you only change the port redirection in docker-compose.
When I ran the Mosquitto (MQTT) broker for the first time there was no issue. However when running it for the second time using the default config I could not run the code successfully because of the following error on Windows 8:
1379497253: mosquitto version 1.2 (build date 2013-09-17 17:59:39+0530) starting 1379497253: Using default config. 1379497253: Opening ipv6 listen socket on port 1883. 1379497253: Error: Address already in use
How can I resolve this error, or more importantly what does this error mean?
Address already in use usually means that the port (in your case 1883) is already being used by another process. The most likely situation given your description is that another copy of mosquitto is already running. If you want to run two (or more) you'll need to configure each to use a separate port number.
You have to check the mosquitto.conf in a bin folder in which you installed the mosquitto server.
Make sure all lines are commented with '#' especially the following line,
port 1883 or listener 1883.
then, find some available port or whether the port 1883 is used by using command like netstat.
In windows, you can use this,
netstat -an| findStr 1883
You have to change your default port on mosquitto when found any message from the prompt.
Append some specific number on the line below which is indicating the port whatever you prefer to.
listener XXX
protocol mqtt
I'm developing an MQTT based application using HiveMQ, an enterprise broker. I installed it as per the instructions here- http://www.hivemq.com/docs/hivemq/2.0.1/
When I run it using ./bin/run.sh, the server connection is immediately closed due to the error - Could not bind to all interfaces and port 1883, because it is already in use. Stopping HiveMQ
As far as I'm aware, nothing else is using this port. This happens even when I restart my computer and nothing else is running. I'm running in root mode.
Why am I getting this error?
To check if something is already running on the port, please type the following into the terminal if you happen to run a Linux / BSD / OSX:
netstat -an|grep 1883
If you're running a Windows System, type the following:
netstat -an|find "1883"
After running that command you should see which application is using port 1883.
Alternatively you could edit the configuration.properties file in you conf folder of the HiveMQ installation and set the global.port property to a port of your choice.
From those results, do you have d-bus daemon installed? I don't know much about d-bus, but have you tried disabling it or modifying the config and then see if you can restart hivemq on port 1883.
I am new to Java and I'm facing a problem in connecting a Remote Host to the JVisualVM.
I've searched the Internet and followed all the steps mentioned there but still am not able to resolve the issue. The steps I followed are:
I started the jstatd on the remote server by first creating a jstatd.all.policy file in the $JAVA_HOME/bin. The file contained: grant codebase "file:${java.home}/../lib/tools.jar" { permission java.security.AllPermission;};
I started the Jstatd as jstatd -J-Djava.security.policy=jstatd.all.policy
I started the Java application on the remote host as :
java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9000 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false application_name
I then started as instance of the JVisualVM on my local machine and as I added the remote host, it got connected but i wasn't able to see any of the Java processes.
Can anyone please help me with this.
Thanks.
I encountered similar problems when connecting to Glassfish application server. See solutions that worked for me as they can be same for You:
Try setting on your application:
-Djava.rmi.server.hostname=*Remote_Server_External_IP_Address*
The mentioned IP address should be server external IP (may sound silly but it worked for me). The main problem in my case was JMX pointing to the localhost and looping. In config files the exact IP address should be set to the remote host. I described it as 'Problem 2' In my blog: handling connection problems
If Firewall block is an issue then I recommend trying XMing with SSH tunnel (which is simple to set). Here is instruction, if You encounter problems setting it:
Remote use of VisualVM with Xming (my blog)
Biggest advantage of using XMing is that it will work almost always when SSH is enabled. You just have to place VisualVM files on the remote host and run it from command line. XWindow will show VisualVM Window on Your local computer.
There is a chance that it is VisualVM issue - try using some other tool just to verify what is wrong. I recommend JConsole. It works similar to VisualVM and I also described details on my blog
You need to start jstatd with the additional option that points to the server's external IP or hostname:
statd -J-Djava.security.policy=jstatd.all.policy -J-Djava.rmi.server.hostname=my_server_ip/hostname
Answer based on: https://java.net/projects/visualvm/lists/users/archive/2010-03/message/8
To connect to a remote VM you have to start that remote VM with specific options:
java
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9000
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
class
After the VM is started, go to your VisualVM and do the following:
File -> Add JMX Connection
Type: yourHostName:9000 and click OK
On the left you will have the added JMX connection, double click on it and that's it!
More details on the Java Monitoring and Management Platform can be found here.
Here are the steps to do this:
Launch an ejstatd in your remote host this way (in ejstatd folder): mvn exec:java -Djava.rmi.server.hostname=<remote_host_name> -Dexec.args="-pr 1099 -ph 1100 -pv 1101" (used for "jstatd" type connection) (only specify -Djava.rmi.server.hostname if the hostname of your remote host does not match with the one you are seeing from your local network)
Launch your Java application with those additional Java parameters: -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=1102 -Dcom.sun.management.jmxremote.rmi.port=1102 -Djava.rmi.server.hostname=<remote_host_name> (used for "JMX" type connection) (same remark as the previous point for -Djava.rmi.server.hostname)
Open those 4 ports on your remote host and make them available to your local machine: 1099, 1100, 1101 and 1102
Launch JVisualVM
Right-click on "Remote" > "Add Remote Host..." and enter your remote host name in "Host name" (if you don't use the port 1099, you can change this in the "Advanced Settings")
Right-click on the remote host you've just created > "Add JMX Connection..." and enter "<remote_host_name>:1102" in "Connection" input, and check "Do not require SSL connection"
Your Java process will appear twice: one from the "jstatd" connection type, and one from the "JMX" connection type.
Disclaimer: I'm the author of the open source ejstatd tool.
Start jstatd in nohup on the server which needs to be monitored and connect VisualVM to the jstatd port, following below steps:
Step 1 : Create start-jstatd.sh and copy the below content:
nohup jstatd -p 1099 -J-Djava.security.policy=<(echo 'grant codebase "file:${java.home}/../lib/tools.jar" {permission java.security.AllPermission;};') &
Step 2: Give executable permission to the file:
$ chmod a+rwx start-jstatd.sh
Step 3: Start jstatd:
$ sh start-jstatd.sh
Step 4: Add Remote Host in VisualVM:
Step 5: Add JMX Connection to the Remote Host, as shown in the below image and Click OK button: