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've been searching high and low for a simple explanation for this. What configuration settings do I use to connect my Sonoff RF bridge to the Mosquitto server on my computer? I'm sure it's a configuration issue but most of the tutorials out there are for rPi. My skill level in this is basic and I'm sure it may be obvious to someone what's wrong.
I'm running Mosquitto on Windows 10 and have verified that the Mosquitto server is running using netstat -a (I can see the broker is listening at 0.0.0.0:1883.
I've installed Tasmota Eclipse on my Sonoff RF Bridge and have verified it is receiving signal from my door sensor by opening the UI in my browser and viewing the console. I've tried multiple host addresses in the configuration menu; localhost, 0.0.0.0, 10.0.0.1, however Tasmota only seems to connect when I leave the host field blank.
I've tried to use MQTTlens to verify that the broker is receiving messages on port 1883 and nothing seems to be coming through.
0.0.0.0 is a short hand to tell mosquitto to listen on all the available interfaces on the machine it is running on. It is meaningless to use it in the client configuration.
Likewise, localhost always means the same machine that the code making the request is running on, so in this case it would be the Sonoff device it's self.
It looks like 10.0.0.1 is the address of your local router, unless mosquitto is actually running on the router (it is very unlikely your windows machine is your router) this again is not going to be useful.
You need to use the IP address of the Windows machine that mosquitto is running on, this is going to start with 10.0.0. running ipconfig on the command line in windows is probably the quickest/simplest way to find that address.
I'm trying to use UPnP to open a port, so I'm experimenting with miniupnpc. I've observed a handful of people use and suggest upnpc -a <internal ip> <internal port> <external port> <protocol> to open the specified external port and point it to the application running on the specified internal port.
Before I continue, I will note that UPnP is on in my router's settings, and that it lists a few connections, though when I check them with a port checker I find that none of them are actually working? Or at least none of them seem to be open.
When I try to map the internal port 5000 to the external port 7777 with the following command:
upnpc -a 192.168.1.10 5000 7777 tcp
What I find is that it "works" without any explicit errors, but
the external ip it maps to isn't really an external ip at all. Here's the output following the command given above:
upnpc : miniupnpc library test client, version 2.1.
(c) 2005-2019 Thomas Bernard.
Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/
for more information.
List of UPNP devices found on the network :
desc: http://192.168.1.1:5000/Public_UPNP_gatedesc.xml
st: urn:schemas-upnp-org:device:InternetGatewayDevice:1
Found a (not connected?) IGD : http://192.168.1.1:5000/Public_UPNP_C3
Trying to continue anyway
Local LAN ip address : 192.168.1.10
ExternalIPAddress = 192.168.0.153
InternalIP:Port = 192.168.1.10:5000
external 192.168.0.153:7777 TCP is redirected to internal 192.168.1.10:5000 (duration=0)
Obviously, 192.168.0.153 is not an external IP Address, and yet it seems to be treating it as though it is. Why might this be?
EDIT: Upon further inspection, it seems like since I have a multi-router set up, the "external ip" here is actually the internal ip of the secondary router. I wonder why this is, though, and whether it can be circumvented.
I am attempting to bind a socket to a port below:
if( bind(socket_desc,(struct sockaddr *) &server, sizeof(server)) < 0)
{
perror("bind failed. Error");
return 1;
}
puts("bind done");
But it gives:
$ ./serve
Socket created
bind failed. Error: Address already in use
Why does this error occur?
Everyone is correct. However, if you're also busy testing your code your own application might still "own" the socket if it starts and stops relatively quickly. Try SO_REUSEADDR as a socket option:
What exactly does SO_REUSEADDR do?
This socket option tells the kernel that even if this port is busy (in
the TIME_WAIT state), go ahead and reuse it anyway. If it is busy,
but with another state, you will still get an address already in use
error. It is useful if your server has been shut down, and then
restarted right away while sockets are still active on its port. You
should be aware that if any unexpected data comes in, it may confuse
your server, but while this is possible, it is not likely.
It has been pointed out that "A socket is a 5 tuple (proto, local
addr, local port, remote addr, remote port). SO_REUSEADDR just says
that you can reuse local addresses. The 5 tuple still must be
unique!" by Michael Hunter (mphunter#qnx.com). This is true, and this
is why it is very unlikely that unexpected data will ever be seen by
your server. The danger is that such a 5 tuple is still floating
around on the net, and while it is bouncing around, a new connection
from the same client, on the same system, happens to get the same
remote port. This is explained by Richard Stevens in ``2.7 Please
explain the TIME_WAIT state.''.
You have a process that is already using that port. netstat -tulpn will enable one to find the process ID of that is using a particular port.
Address already in use means that the port you are trying to allocate for your current execution is already occupied/allocated to some other process.
If you are a developer and if you are working on an application which require lots of testing, you might have an instance of your same application running in background (may be you forgot to stop it properly)
So if you encounter this error, just see which application/process is using the port.
In linux try using netstat -tulpn. This command will list down a process list with all running processes.
Check if an application is using your port. If that application or process is another important one then you might want to use another port which is not used by any process/application.
Anyway you can stop the process which uses your port and let your application take it.
If you are in linux environment try,
Use netstat -tulpn to display the processes
kill <pid> This will terminate the process
If you are using windows,
Use netstat -a -o -n to check for the port usages
Use taskkill /F /PID <pid> to kill that process
The error usually means that the port you are trying to open is being already used by another application. Try using netstat to see which ports are open and then use an available port.
Also check if you are binding to the right ip address (I am assuming it would be localhost)
if address is already in use can you just want to kill whoso ever process is using the port, you can use
lsof -ti:PortNumberGoesHere | xargs kill -9
source and inspiration this.
PS: Could not use netstat because it not installed already.
As mentioned above the port is in use already.
This could be due to several reasons
some other application is already using it.
The port is in close_wait state when your program is waiting for the other end to close the program.refer (https://unix.stackexchange.com/questions/10106/orphaned-connections-in-close-wait-state).
The program might be in time_wait state. you can wait or use socket option SO_REUSEADDR as mentioned in another post.
Do netstat -a | grep <portno> to check the port state.
It also happens when you have not give enough permissions(read and write) to your sock file!
Just add expected permission to your sock contained folder and your sock file:
chmod ug+rw /path/to/your/
chmod ug+rw /path/to/your/file.sock
Then have fun!
I was also facing that problem, but I resolved it.
Make sure that both the programs for client-side and server-side are on different projects in your IDE, in my case NetBeans. Then assuming you're using localhost, I recommend you to implement both the programs as two different projects.
To terminate all node processes:
killall -9 node
First of check which port are listening,
netstat -tlpn
then select available port to conect,
sudo netstat -tlpn | grep ':port'
Fix it into also to your server and clients interfaces. Go Barrier tab -> change settings, -> port value type -> save/ok
Check both clients and server have similar port values
Then Reload.
Now it should be ok.
Check for running process pid:
pidof <process-name>
Kill processes:
sudo kill -9 process_id_1 process_id_2 process_id_3
I made a C# program with a client and a server that comunicates fine between them. Information is received by the server and stored in a MySQL Database with no problems. However I wanted to use wireshark to monitor how safe/encrypted was the information and couldn't find the communication using wireshark. My program uses sockets to connect the server and client, on my test the server and client are running at adress 127.0.0.1 or local IP machine (something like 192.168.13.191), server listens/connects using port 3608 and client a much higher random port, and all the filters I used on wireshark return nothing.
So far I tried:
ip.addr == 127.0.0.1 (show only packages whose origin or destination are 127.0.0.1)
ip.addr == 192.168.13.191 (same as above)
tcp.port == 3608 (show only packages whose origin or destination is this port)
tcp.port == client_port (same as above)
tcp contains 01:00:00:3B (only packages with a few of the bytes I'm sending)
My idea was to find at least one message from the client to server and use the "Follow TCP stream" option from wireshark, but all these filters return a black screen when used individually. I have no idea why, because when I run netstat -a on a windows command I can see the program have a established connection and is also listening for new connections on port 3608. Anyone have any idea what is going on or what filter should I use? Operational system somehow is "redirecting" traffic from port 3608 to another?
Thanks!
Wireshark doesn't pick up loopback packets. You'll have to install the client or server on another machine and then try again.
EDIT: After doing some reading I've discovered that this really doesn't have anything to do with Wireshark but with the way WinPcap works. In any case, running the client or server on another machine will solve the problem.