1

I'm using Eclipse's Paho MQTT library to stream DAQ data to a PC.

It all works fine using the cloud based Eclipse test broker over WiFi. Unfortunately my application will be in a place where there is no WiFi available. So I'm trying to do this through a LAN via the ethernet port using Mosquitto as a local broker. To be clear the application will have no internet access via either WiFi or LAN. The network needs to be just Pi to PC.

Raspberry Pi: Client: DAQ >> local broker >> eth0 >> PC: Client

I can ping my Pi from the PC successfully and the DAQ code connects with the local broker with no error & broadcasts its data.

But on the PC: Client side I get the following error,

ConnectionRefusedError: [WinError 10061] No connection could be made because the target machine actively refused it

Is there some security lock out going on here?

goldilocks
  • 60,325
  • 17
  • 117
  • 234
DrBwts
  • 199
  • 3
  • 14

2 Answers2

1

By default Mosquitto's broker sets itself up as local host ONLY. You have to place a .conf file in /etc/mosquitto/conf.d/ with whatever access rules you want to set for remote access.

Mosquitto - authentication methods

As to why this is happening, this from a comment to the OP from goldilocks,

... what's happening is the server binds itself to the local loopback interface (via localhost / 127.0.0.1), hence nothing is listening on the same port via the inet interface (wlan or eth), so the OS refuses the connection via the TCP mechanism

DrBwts
  • 199
  • 3
  • 14
0

Is there some security lock out going on here?

No; that is not a firewall response. "Connection refused" is normal and commonplace. The OS does this when you try to connect to a port nothing is listening on, see: https://unix.stackexchange.com/a/73782/25985 This is scenario #3 described there.

You can confirm this by:

  • Watching the TCP exchange in a tool like wireshark.
  • Setting the port to one you know is not being used; the result will be the same.
  • Searching online for ConnectionRefusedError: [WinError 10061]. There are copious further explanations of the above.

Possible reasons for this:

  • You have the IP address wrong and the refusing system is not the Pi.
  • The server you think is running is not running or is configured to use a different port.
  • The server is bound to a different interface than the one with the IP address you are using. For example, it is possible to bind only to the loopback interface (127.0.0.1), which is not accessible remotely. Active interfaces generally (but not necessarily) have a 1:1 relationship with an IP address.
goldilocks
  • 60,325
  • 17
  • 117
  • 234