0

I'm trying to create mqtt connection using python. The shortest code to reproduce the problem is

import paho.mqtt.client as paho

client = paho.Client('myClient')
client.username_pw_set('user', 'password')
client.connect('my.broker.com')

On the last line I get

ConnectionRefusedError: [Errno 111] Connection refused

Interesting that connection is not refused by server. connect() has logging and it seems that connection is refused before the actual request.

I tried the script on Windows machine and it works fine as well as on Ubuntu, but I need to run it on the machine with Fedora 37 (which refuses the connection). I believe there is some misconfiguration, but I have basic Linux knowledge and don't know where I can look to find it. I don't know current states of both Linuxes, they may be set up somehow, but Windows machine have pretty default settings. I have googled and saw some recomendations like:

  • Run local mqtt broker (not suitable for me as I have to connect to the remote broker)
  • Check the firewall rules (I believe there is no firewall in the network, as other machines can connect to the broker)
  • Check iptables (it shows no filtering rules)

Are there any suggestions on what else I can check? Are there any Fedora-specific or Linux-wide restrictions on socket creation?

4
  • 1
    Can you ping (name resolving and a response) for my.broker.com? If the server is listening on port 12345, can you nc -vvv my broker.com 12345 and get a Connected! response? Commented May 22, 2023 at 19:57
  • ping shows 100% packet loss. nc shows connection refused. Commented May 23, 2023 at 8:35
  • Does ping resolve the name to the correct IP address? Commented May 23, 2023 at 8:42
  • Yes. What can be the issue in that case? Commented May 23, 2023 at 8:51

1 Answer 1

1

Unix-wide:

Normally only root can use ports numbered 1023 or less, but since MQTT default port number is 1883, that should not be a problem.

Fedora-specific:

Fedora uses SELinux by default, but that should not restrict interactive sessions of regular users in ways that would apply here. But if you are running your script through some service (e.g. as a webserver CGI script or something), your script might be prevented from opening outgoing network connections unless SELinux is configured to allow it.

Basic connectivity testing:

If you have telnet or netcat (nc) installed, test connectivity with:

telnet my.broker.com 1883

or

nc -v my.broker.com 1883

respectively.

If you have traceroute installed, run a TCP traceroute on the specific port your application needs (1883 is the default for MQTT with no SSL/TLS):

sudo traceroute -T -p 1883 my.broker.com

If a basic TCP connection to the broker can be successfully established, both telnet and nc will explicitly tell you so.

If something on the network is dropping the connection attempt, traceroute -T should help you identify that thing.

5
  • Have no telnet, but nc my.broker.com 1883 returned Ncat: Connection refused even with sudo. What does it mean? Traceroute, seems show no errors. It resolves ip address of the broker. Commented May 23, 2023 at 8:32
  • It means either my.broker.com or some firewall actively rejected the connection. If you are sure the broker is running and listening on TCP port 1883, then there must be a software or hardware firewall filtering the traffic at some point. If the last line of traceroute showed the address of my.broker.com and sensible round-trip times (and no error annotations like !X for example), then the filtering must happen on the my.broker.com system. Note that modern Linux systems may be using netfilter instead of iptables (run nft list ruleset as root/with sudo to see if configured). Commented May 23, 2023 at 12:13
  • Yes, I'm sure about the brocker. Other machines can connect to the same brocker using the same commands (and yes, connect() has the second optional argument port which defaults to 1883). traceroute shows correct ipaddress, time about 0.2 ms, and no !X annotations. This Fedora have no nft installed. How can I check SELinux settings? Commented May 23, 2023 at 12:45
  • sestatus or getenforce should indicate if SELinux is enabled in enforcing mode. Actual configuration of SELinux is however not exactly a small topic. Commented May 23, 2023 at 13:08
  • $ getenforce Enforcing Yeah. SELinux is very difficult to configure. Tried to choose the simple way - to disable it - but it does not help. Seems, that you are right. And the only possible reason is some device somewhere in the network. Thank you very much! Commented May 23, 2023 at 14:05

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.