Issue: cannot install Mosquitto under Raspbian Stretch, following instructions at https://mosquitto.org/2013/01/mosquitto-debian-repository/ with http://repo.mosquitto.org/debian/mosquitto-stretch.list

Error: pi@raspberrypi:/etc/apt/sources.list.d $ sudo apt-get install mosquitto Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation:

The following packages have unmet dependencies: mosquitto : Depends: libssl1.0.0 (>= 1.0.1) but it is not installable Depends: libwebsockets3 (>= 1.2) but it is not installable E: Unable to correct problems, you have held broken packages.

Hello,

I am unable to connect to my local Mosquitto 1.4.10 broker from a JavaScript client over a websocket.

The same JavaScript client is successfully connecting to the public broker at test.mosquitto.org on port 8080 over a websocket.

The MQTT protocol connection on port 1883 is working fine, which I tested using mosquitto_pub and mosquitto_sub.

My broker is set up within a VirtualBox running Ubuntu 14.04.

I have libwebsockets installed on the same virtual machine.

My local broker was compiled with WITH_WEBSOCKETS:=yes in the config.mk file

I confirmed by running sudo netstat that the Websockets port is open.

I am loading the JavaScript client web page from a Firefox browser, from inside the same virtual machine on which Mosquitto is running. I get the following error message in the browser console (Apache web server is running on the same virtual machine as Mosquitto):

Firefox can't establish a connection to the server at ws://localhost:8080/mqtt

I did a trace through Wireshark and it seems that the client is getting no response from the server after sending the initial HTTP request to upgrade to the Websockets protocol (see trace below).

As far as I can tell, the issue lies in the Mosquitto installation. Whether it is a bug or something missing in my setup, I cannot tell.

It might help, for starters, if I could look at the .conf file set up for the test.mosquitto.org installation, so I may compare it to my settings.

Any other suggestions on fixing this will be greatly appreciated.

Thanks.

Here is my Mosquitto .conf file:

 	port 1883
 	listener 8080
 	protocol websockets
 
 	log_type all
 	websockets_log_level 1023
 	connection_messages true

Here is the Mosquitto server's log (with websockets logging level set to 1023, and verbose logging turned on - no messages appear when I load the JavaScript web page):

1481381105: mosquitto version 1.4.10 (build date 2016-12-10 18:47:37+0530) starting 1481381105: Config loaded from /etc/mosquitto/mosquitto.conf. 1481381105: Opening websockets listen socket on port 8080. 1481381105: Initial logging level 1023 1481381105: Libwebsockets version: 2.1.0 manavkumarm@manav-alljoyn- 1481381105: IPV6 not compiled in 1481381105: libev support not compiled in 1481381105: libuv support not compiled in 1481381105: Threads: 1 each 1024 fds 1481381105: mem: platform fd map: 4096 bytes 1481381105: Compiled with OpenSSL support 1481381105: Creating Vhost 'default' port 8080, 3 protocols, IPv6 off 1481381105: Using non-SSL mode 1481381105: Listening on port 8080 1481381105: mem: per-conn: 376 bytes + protocol rx buf 1481381105: canonical_hostname = mqtt 1481381105: Opening ipv4 listen socket on port 1883. 1481381105: Opening ipv6 listen socket on port 1883.

Here is the Wireshark trace:

GET /mqtt HTTP/1.1 Host: localhost:8080 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:49.0) Gecko/20100101 Firefox/49.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Sec-WebSocket-Version: 13 origin: http://localhost Sec-WebSocket-Protocol: mqtt Sec-WebSocket-Extensions: permessage-deflate Sec-WebSocket-Key: 2jGKB8w/B3al/XajJp3o6g== Connection: keep-alive, Upgrade Pragma: no-cache Cache-Control: no-cache Upgrade: websocket

Using Mosquitto 1.4.10 (and 1.4.8), we get segfaults when a websocket client has been running for a while. The segfault seems to orinate in libwebsockets 1.7 (shipped with Ubuntu 16.04), but but because it's running a callback function, it may actually be Mosquitto. I tried using the newest libwebsockets 2.1 stable, but then it crashes on handshake.

Perhaps related, there is a fair amount of SIGPIPE broken pipe signals for which I see no apparent reason. We can reproduce this with many TCP clients and one websocket client. There doesn't seem to be a good reason why that websocket client keeps losing its connection. Additionally, before the stack trace, it always seems to have done authentication with HTTP (http://127.0.0.1:80/auth/). The current client is programmed to reconnect after a broken connection, so it appears as though the sequence is disconnect-reconnect-auth-crash.

See below for a stack trace when running Mosquitto 1.4.10 with libwebsockets 1.7.

A core dump is also available, but that probably does contain sensitive information, because we could only reproduce this issue on our live server with enough traffic.

1478092472: |-- aclcheck(xxx, N/04a316b4f85b/battery/260/History/TimeSinceLastFullCharge, 2) CACHEDAUTH: 0
1478092472: |-- mosquitto_auth_acl_check(..., xxx, xxx, N/6cecebc44ede/hub4/0/MaxChargePower, MOSQ_ACL_WRITE)
1478092472: |-- aclcheck(xxx, N/6cecebc44ede/hub4/0/MaxChargePower, 2) CACHEDAUTH: 0
1478092472: |-- mosquitto_auth_acl_check(..., xxx, ccxxx, N/6cecebc44ede/hub4/0/MaxDischargePower, MOSQ_ACL_WRITE)
1478092472: |-- aclcheck(xxx, N/6cecebc44ede/hub4/0/MaxDischargePower, 2) CACHEDAUTH: 0
1478092472: |-- mosquitto_auth_acl_check(..., xxx, xxx, N/d05fb8999e85/system/0/Ac/PvOnGrid/L1/Power, MOSQ_ACL_WRITE)
1478092472: |-- aclcheck(xxx, N/d05fb8999e85/system/0/Ac/PvOnGrid/L1/Power, 2) CACHEDAUTH: 0
1478092472: |-- mosquitto_auth_acl_check(..., xxx, xxx, N/d05fb8999e85/battery/258/Dc/0/Power, MOSQ_ACL_WRITE)
1478092472: |-- aclcheck(xxx, N/d05fb8999e85/battery/258/Dc/0/Power, 2) CACHEDAUTH: 0
1478092472: |-- mosquitto_auth_acl_check(..., ccxxx, xxx, N/6ceceb80aeb1/vebus/257/Dc/0/Voltage, MOSQ_ACL_WRITE)
1478092472: |-- aclcheck(xxx, N/6ceceb80aeb1/vebus/257/Dc/0/Voltage, 2) CACHEDAUTH: 0
1478092472: |-- mosquitto_auth_acl_check(..., xxx, xxx, N/6ceceb8d5c2b/solarcharger/0/Yield/Power, MOSQ_ACL_WRITE)
1478092472: |-- aclcheck(xxx, N/6ceceb8d5c2b/solarcharger/0/Yield/Power, 2) CACHEDAUTH: 0
1478092472: |-- mosquitto_auth_unpwd_check([email protected])
1478092472: |-- ** checking backend http
1478092472: |-- url=http://127.0.0.1:80/auth/
1478092472: |-- data=username=info%40example.com&password=hello123&topic=&acc=-1&clientid=
1478092473: |-- getuser([email protected]) AUTHENTICATED=1 by http

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6bf7a0c in ?? () from /usr/lib/x86_64-linux-gnu/libwebsockets.so.7
(gdb) 
(gdb) 
(gdb) where
#0  0x00007ffff6bf7a0c in ?? () from /usr/lib/x86_64-linux-gnu/libwebsockets.so.7
#1  0x00007ffff6bf8099 in lws_callback_on_writable () from /usr/lib/x86_64-linux-gnu/libwebsockets.so.7
#2  0x000000000040d591 in do_disconnect (db=db@entry=0x6268e0 <int_db>, context=context@entry=0x2805000) at loop.c:404
#3  0x0000000000414b2c in mqtt3_handle_connect (db=0x6268e0 <int_db>, context=0x7a6f40) at read_handle_server.c:476
#4  0x000000000041ccd6 in callback_mqtt (wsi=<optimized out>, reason=<optimized out>, user=<optimized out>, in=0x665e10, len=66) at websockets.c:363
#5  0x00007ffff6bf6797 in ?? () from /usr/lib/x86_64-linux-gnu/libwebsockets.so.7
#6  0x00007ffff6bfae13 in ?? () from /usr/lib/x86_64-linux-gnu/libwebsockets.so.7
#7  0x00007ffff6c03140 in ?? () from /usr/lib/x86_64-linux-gnu/libwebsockets.so.7
#8  0x00007ffff6bf4e5e in lws_read () from /usr/lib/x86_64-linux-gnu/libwebsockets.so.7
#9  0x00007ffff6bf7564 in lws_service_fd_tsi () from /usr/lib/x86_64-linux-gnu/libwebsockets.so.7
#10 0x00007ffff6c00f5b in lws_plat_service_tsi () from /usr/lib/x86_64-linux-gnu/libwebsockets.so.7
#11 0x000000000040dfeb in mosquitto_main_loop (db=db@entry=0x6268e0 <int_db>, listensock=listensock@entry=0x1ca3a20, listensock_count=listensock_count@entry=2, listener_max=listener_max@entry=6) at loop.c:378
#12 0x0000000000404b36 in main (argc=<optimized out>, argv=<optimized out>) at mosquitto.c:385

I am experiencing quite a high latency when sending two messages in a row (~40 ms). The client receives the first message near instantly but the second message is delayed in the broker. A single message is fine. This behavior is 100% reproducible for me. I tried several things to figure where the delay happens. I hope I am not barking up the wrong tree here. I did the same test with emqttd and there is no delay at all.

Setup:

• Broker mosquitto 1.4.8 at 192.168.2.33 on Ubuntu 16.04.2 LTS in a VM hosted on Windows 10 on an Intel i5.
• Client 1 192.168.2.230 MQTT.fx 1.3.1 on Windows 10
• Client 2 192.168.2.36 Ubuntu using mosquitto_pub
• Client 1 subscribed to topic latency, Client 2 publishes messages to topic latency

This is how the network traffic does look in ngrep when publishing two successive messages to one topic:

T 2017/05/01 17:20:34.695801 192.168.2.36:42932 -> 192.168.2.33:1883 [AP]
  0...latency1
T 2017/05/01 17:20:34.695843 192.168.2.33:1883 -> 192.168.2.230:5747 [AP]
  0...latency1
T 2017/05/01 17:20:34.699322 192.168.2.36:42934 -> 192.168.2.33:1883 [AP]
  0...latency2
T 2017/05/01 17:20:34.736158 192.168.2.33:1883 -> 192.168.2.230:5747 [AP]
  0...latency2

So the message latency1 published by client 192.168.2.36 arrives at the broker at 17:20:34.695801 and is published to client 192.168.2.230 17:20:34.695843. So only 42 us later. Then message latency2 comes in at 17:20:34.699322 but this time the broker publishes it at 17:20:34.736158 to the client. So ~35 ms later. I would expect the same low latency as for the first message.

I think that message2 is held back within the broker machine until the TCP-ACK packet for message1 is received, which is quite strange IMO.

I am reproducing this as follows:

1. On Client 2: Publish two messages in a row to one topic mosquitto_pub -h 192.168.2.33 -t latency -m 1; mosquitto_pub -h 192.168.2.33 -t latency -m 2
2. On the broker machine (192.168.2.33) I am using ngrep to see timestamps for incoming and outgoing messages: ngrep latency -q -t
3. ngrep output is (as seen above):

T 2017/05/01 17:20:34.695801 192.168.2.36:42932 -> 192.168.2.33:1883 [AP]
  0...latency1
T 2017/05/01 17:20:34.695843 192.168.2.33:1883 -> 192.168.2.230:5747 [AP]
  0...latency1
T 2017/05/01 17:20:34.699322 192.168.2.36:42934 -> 192.168.2.33:1883 [AP]
  0...latency2
T 2017/05/01 17:20:34.736158 192.168.2.33:1883 -> 192.168.2.230:5747 [AP]
  0...latency2

I can see using strace with command sudo strace -p 80684 -e read,write -rthat the process mosquitto is writing the network message to the socket as soon as it read the message from the incoming socket:

strace: Process 80684 attached
     0.000000 read(11, "sendmail: all\n# /etc/hosts.allow"..., 4096) = 425
     0.000112 read(11, "", 4096)        = 0
     0.000114 read(11, "# /etc/hosts.deny: list of hosts"..., 4096) = 711
     0.000038 read(11, "", 4096)        = 0
     0.000176 read(10, "\20", 1)        = 1
     0.000039 read(10, "\"", 1)         = 1
     0.000033 read(10, "\0\6MQIsdp\3\2\0<\0\24mosqpub/10847-ubun"..., 34) = 34
     0.000074 write(3, "1493653233: Sending CONNACK to m"..., 59) = 59
     0.000059 write(10, " \2\0\0", 4)   = 4
     0.000752 read(10, "0", 1)          = 1
     0.000117 read(10, "\n", 1)         = 1
     0.000207 read(10, "\0\7latency1", 10) = 10
     0.000143 write(9, "0\n\0\7latency1", 12) = 12
     0.000199 read(10, "\340", 1)       = 1
     0.000051 read(10, "\0", 1)         = 1
     0.003352 read(11, "sendmail: all\n# /etc/hosts.allow"..., 4096) = 425
     0.000108 read(11, "", 4096)        = 0
     0.000540 read(11, "# /etc/hosts.deny: list of hosts"..., 4096) = 711
     0.000236 read(11, "", 4096)        = 0
     0.000592 read(10, "\20", 1)        = 1
     0.000157 read(10, "\"", 1)         = 1
     0.000165 read(10, "\0\6MQIsdp\3\2\0<\0\24mosqpub/10848-ubun"..., 34) = 34
     0.000080 write(10, " \2\0\0", 4)   = 4
     0.000786 read(10, "0", 1)          = 1
     0.000195 read(10, "\n", 1)         = 1
     0.000181 read(10, "\0\7latency2", 10) = 10
     0.000080 write(9, "0\n\0\7latency2", 12) = 12
     0.000445 read(10, "\340", 1)       = 1
     0.000103 read(10, "\0", 1)         = 1
     0.164655 read(8, "1", 1)           = 1
     0.000078 read(8, "&", 1)           = 1
     0.000066 read(8, "\0\35home/rgbww_a020a61624ea/clock1"..., 38) = 38

The lines in question:

     0.000207 read(10, "\0\7latency1", 10) = 10
     0.000143 write(9, "0\n\0\7latency1", 12) = 12

and

     0.000181 read(10, "\0\7latency2", 10) = 10
     0.000080 write(9, "0\n\0\7latency2", 12) = 12

Only a few microseconds between reading and writing the data which seems great.

But when using Wireshark to analyze whats happening on the TCP stack we can see that message1 arrives at the broker and gets published to client2 very quickly. Then message2 arrives but it is not published to client2 immediately. It only gets published right after the ACK packet from client2 for message1 arrives at the broker:

So is this an expected behavior with mosquitto? For me it seems like Linux TCP stack is holding the second packet back which would not be a mosquitto issue then, but as I said when I try with emqttd then everything is fine.

Since upgrading to Mosquitto 2.0.2 I get the following error upon starting Mosquitto:

mosquitto -c mosquitto.conf
1607938526: Loading config file /etc/mosquitto/conf.d/default.conf 2020-12-14T10:35:26: Error: Unable to write pid file.

My conf file is as follows:

# Place your local configuration in /etc/mosquitto/conf.d/ # # A full description of the configuration file is at # /usr/share/doc/mosquitto/examples/mosquitto.conf.example

pid_file /var/run/mosquitto.pid

persistence true persistence_location /var/lib/mosquitto/

log_dest file /var/log/mosquitto/mosquitto.log log_timestamp_format %Y-%m-%dT%H:%M:%S log_type all

include_dir /etc/mosquitto/conf.d

Is this a bug or a misconfiguration on my side?

The system is: Ubuntu 20.04

I understand what this error is but still having real issues with this. I left it for around a year as it was just annoying me but I need to get this back up and running. Today I have reinstalled libwebsockets and with mosquitto 1.4.9, 1.4.10, 1.4.13 I have edited the config.mk file to use websockets. make, make install and attempted to restart mosquitto with the websockets running and still I get:

Starting Mosquitto MQTT brokerError: Websockets support not available.

Totally lost as to what is going on, if anyone can shed some light would be great. TIA

After today's update for docker images: eclipse-mosquitto:1.5.3, eclipse-mosquitto:1.5 and eclipse-mosquitto:latest docker container does not accept websocket connections

How I start docker container:

docker run --detach -p 1883:1883 -p 8000:8000 -v mosquitto/config:/mosquitto/config eclipse-mosquitto

Content my mosquitto.conf:

log_dest syslog
port 1883
listener 8000
protocol websockets

As a temporary workaround I start docker container with tag "1.4.12":

docker run --detach -p 1883:1883 -p 8000:8000 -v mosquitto/config:/mosquitto/config eclipse-mosquitto:1.4.12

After upgrading to the latest OpenSSL version to fix the recent security vulnerability, I get the following:

[FAILED] Starting Mosquitto MQTT brokerError: Websockets support not available. Error found at /etc/mosquitto/conf.d/mosquitto.conf:42. Error found at /etc/mosquitto/mosquitto.conf:10. Error: Unable to open configuration file.

I have rebuilt Mosquitto 1.4.8 and still the same message despite rebuilding with Websockets = yes. It was previously working before upgrade to latest OpenSSL and was definitely functioning correctly.

Anyone experienced this or know how to get around ? TIA

Hi,

I have one broker process running from long time and with ps I can see the process, but it is not accepting connections.

vinod_kumar@mqtt-broker-2:~$ ps aux|grep -i mosquitto
vinod_k+  3865  0.0  0.0   8212  2164 pts/2    S+   05:11   0:00 grep --color=auto -i mosquitto
mosquit+ 25389  0.1  0.1  39688  5652 ?        R     2016 594:16 mosquitto -c mosquitto.conf -d

vinod_kumar@mqtt-broker-2:~$ mosquitto_sub -t hello -d
Error: Connection refused

The process is using far more than normal cpu usage Output of top -

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                                                                                                          
25389 mosquit+  20   0   39688   5652   4188 R 99.9  0.1 584:37.48 mosquitto  

I am using old version of mosquitto, so not sure if this issue is fixed in newer releases, though I checked and could not find any fix directly stating the problem I am facing. Mosquitto version

mosquitto version 1.4.5 (build date Mon, 09 Nov 2015 15:00:46 +0000)
mosquitto is an MQTT v3.1 broker.

OS version

vinod_kumar@mqtt-broker-2:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 15.04
Release:	15.04
Codename:	vivid

Mosquitto conf

vinod_kumar@mqtt-broker-2:~$ cat mosquitto.conf 
autosave_interval 100
persistence true
persistence_file m2.db
persistence_location ./
connection_messages true
log_timestamp true
listener 1883
listener 1884 127.0.0.1
protocol websockets
allow_duplicate_messages false
max_connections -1
max_inflight_messages 50
max_queued_messages 1000
persistent_client_expiration 3m
sys_interval 1

Output of memleax

vinod_kumar@mqtt-broker-2:~$ sudo memleax 25389
Warning: no debug-line found for /usr/sbin/mosquitto
== Begin monitoring process 25389...
CallStack[1]: memory expires with 80 bytes, backtrace:
    0x00007fb3dcc5d4a0  libc-2.21.so  __libc_malloc()+0  /build/buildd/glibc-2.21/malloc/hooks.c:77
    0x000000000040e666  mosquitto
    0x000000000040c291  mosquitto
    0x000000000040c566  mosquitto
    0x000000000041a783  mosquitto
    0x000000000040daac  mosquitto
    0x0000000000404a58  mosquitto
    0x00007fb3dcbf9a40  libc-2.21.so  __libc_start_main()+240  /build/buildd/glibc-2.21/stdio-common/_i18n_number.h:117
    0x0000000000404c87  mosquitto
CallStack[2]: memory expires with 1 bytes, backtrace:
    0x00007fb3dcc5d4a0  libc-2.21.so  __libc_malloc()+0  /build/buildd/glibc-2.21/malloc/hooks.c:77
    0x00007fb3dcc6442a  libc-2.21.so  strdup()+26  /build/buildd/glibc-2.21/string/strdup.c:42
    0x000000000040e736  mosquitto
    0x000000000040c2ba  mosquitto
    0x000000000040c566  mosquitto
    0x000000000041a783  mosquitto
    0x000000000040daac  mosquitto
    0x0000000000404a58  mosquitto
    0x00007fb3dcbf9a40  libc-2.21.so  __libc_start_main()+240  /build/buildd/glibc-2.21/stdio-common/_i18n_number.h:117
    0x0000000000404c87  mosquitto
CallStack[3]: memory expires with 19 bytes, backtrace:
    0x00007fb3dcc5d4a0  libc-2.21.so  __libc_malloc()+0  /build/buildd/glibc-2.21/malloc/hooks.c:77
    0x00007fb3dcc6442a  libc-2.21.so  strdup()+26  /build/buildd/glibc-2.21/string/strdup.c:42
    0x000000000040e736  mosquitto
    0x000000000040c2f8  mosquitto
    0x000000000040c566  mosquitto
    0x000000000041a783  mosquitto
    0x000000000040daac  mosquitto
    0x0000000000404a58  mosquitto
    0x00007fb3dcbf9a40  libc-2.21.so  __libc_start_main()+240  /build/buildd/glibc-2.21/stdio-common/_i18n_number.h:117
    0x0000000000404c87  mosquitto
CallStack[4]: memory expires with 16 bytes, backtrace:
    0x00007fb3dcc5d4a0  libc-2.21.so  __libc_malloc()+0  /build/buildd/glibc-2.21/malloc/hooks.c:77
    0x000000000040e666  mosquitto
    0x000000000040c3c6  mosquitto
    0x000000000040c566  mosquitto
    0x000000000041a783  mosquitto
    0x000000000040daac  mosquitto
    0x0000000000404a58  mosquitto
    0x00007fb3dcbf9a40  libc-2.21.so  __libc_start_main()+240  /build/buildd/glibc-2.21/stdio-common/_i18n_number.h:117
    0x0000000000404c87  mosquitto
CallStack[2]: expired-memory frees after 101 seconds
CallStack[3]: expired-memory frees after 101 seconds
CallStack[4]: expired-memory frees after 101 seconds
CallStack[1]: expired-memory frees after 101 seconds
CallStack[1]: memory expires with 80 bytes, 2 times again
CallStack[2]: memory expires with 1 bytes, 2 times again
CallStack[3]: memory expires with 19 bytes, 2 times again
CallStack[4]: memory expires with 16 bytes, 2 times again
CallStack[2]: expired-memory frees after 101 seconds
CallStack[3]: expired-memory frees after 101 seconds
CallStack[4]: expired-memory frees after 101 seconds
CallStack[1]: expired-memory frees after 101 seconds
CallStack[1]: memory expires with 80 bytes, 3 times again
CallStack[2]: memory expires with 1 bytes, 3 times again
CallStack[3]: memory expires with 19 bytes, 3 times again
CallStack[4]: memory expires with 16 bytes, 3 times again
CallStack[2]: expired-memory frees after 101 seconds
Warning: too many expired-free at CallStack[2]. will not show this CallStack later
CallStack[3]: expired-memory frees after 101 seconds
Warning: too many expired-free at CallStack[3]. will not show this CallStack later
CallStack[4]: expired-memory frees after 101 seconds
Warning: too many expired-free at CallStack[4]. will not show this CallStack later
CallStack[1]: expired-memory frees after 101 seconds
Warning: too many expired-free at CallStack[1]. will not show this CallStack later

Output of strace -

Process 25389 attached
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
clock_gettime(CLOCK_MONOTONIC, {34451458, 473126553}) = 0
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {34451458, 473166932}) = 0
clock_gettime(CLOCK_MONOTONIC, {34451458, 473183767}) = 0
clock_gettime(CLOCK_MONOTONIC, {34451458, 473200917}) = 0
clock_gettime(CLOCK_MONOTONIC, {34451458, 473217392}) = 0
rt_sigprocmask(SIG_SETMASK, [INT], [], 8) = 0
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN}], 4, 100) = 1 ([{fd=3, revents=POLLNVAL}])
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
clock_gettime(CLOCK_MONOTONIC, {34451458, 473295297}) = 0
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {34451458, 473352136}) = 0
clock_gettime(CLOCK_MONOTONIC, {34451458, 473379862}) = 0
clock_gettime(CLOCK_MONOTONIC, {34451458, 473397232}) = 0
clock_gettime(CLOCK_MONOTONIC, {34451458, 473413209}) = 0
rt_sigprocmask(SIG_SETMASK, [INT], [], 8) = 0
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN}], 4, 100) = 1 ([{fd=3, revents=POLLNVAL}])
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
clock_gettime(CLOCK_MONOTONIC, {34451458, 473486496}) = 0
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {34451458, 473518710}) = 0
clock_gettime(CLOCK_MONOTONIC, {34451458, 473534360}) = 0
clock_gettime(CLOCK_MONOTONIC, {34451458, 473550677}) = 0
clock_gettime(CLOCK_MONOTONIC, {34451458, 473566255}) = 0
rt_sigprocmask(SIG_SETMASK, [INT], [], 8) = 0
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN}], 4, 100) = 1 ([{fd=3, revents=POLLNVAL}])
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
clock_gettime(CLOCK_MONOTONIC, {34451458, 473637297}) = 0
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {34451458, 473677707}) = 0
clock_gettime(CLOCK_MONOTONIC, {34451458, 473693527}) = 0
clock_gettime(CLOCK_MONOTONIC, {34451458, 473709630}) = 0
clock_gettime(CLOCK_MONOTONIC, {34451458, 473725872}) = 0
rt_sigprocmask(SIG_SETMASK, [INT], [], 8) = 0
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN}], 4, 100) = 1 ([{fd=3, revents=POLLNVAL}])

Please let me know if I can provide anything else to help debug the issue.

docker run eclipse-mosquitto:2.0
1611227315: mosquitto version 2.0.5 starting
1611227315: Config loaded from /mosquitto/config/mosquitto.conf.
1611227315: Starting in local only mode. Connections will only be possible from clients running on this machine.
1611227315: Create a configuration file which defines a listener to allow remote access.
1611227315: Opening ipv4 listen socket on port 1883.
1611227315: Opening ipv6 listen socket on port 1883.
1611227315: Error: Address not available
1611227315: mosquitto version 2.0.5 running

Error: Address not available

I added unix domain socket listener. Because I use mosquitto with Nginx stream proxy on the same machine frequently, it will be better the communication between mosquitto and Nginx can support unix domain socket in order to reduce internal TCP port resources and optimize performance. Plz evaluate it. Thanks. #USAGE: listener unix:<path_name>

Signed-off-by: Tatsuzo Osawa (toast-uz) #

Platform: Windows10 64 bits.

Mosquitto versions: 1.6.9 and 2.0.15

The issue: My client device running on ESP32 can successfully connect to Mosquitto v1.6.9, but after upgrading to v2.0.15 it can no longer connect.

Here's a Wireshark copy of what was happening - RST-ACK on the TCP connect packet:

Where by falling back to 1.6.9, it connects and the error is no longer present:

There was no change in the configurations in both version.

What matters to say is that MQTT-Explorer and mqtt-spy connects with no issues.

What could be my issue?

Browsing through the source code (commit a8448a9c7b14bdaee6ec80419d43fd6544e789b6) I found that in the following files the MT-Unsafe function strerror() is used:

• apps/db_dump/db_dump.c
• client/client_shared.c
• src/bridge.c
• src/conf.c
• src/loop.c:
• src/mux_epoll.c
• src/net.c
• src/persist_read.c
• src/persist_write.c

As the library should be thread safe, I guess strerror_r() should be used instead.

Is it possible to add AF_VSOCK (see man vsock) address family support? This will allow clients in guest machines to bind to mosquitto services running on host side.

Thank you for contributing your time to the Mosquitto project!

Before you go any further, please note that we cannot accept contributions if you haven't signed the Eclipse Contributor Agreement. If you aren't able to do that, or just don't want to, please describe your bug fix/feature change in an issue. For simple bug fixes it is can be just as easy for us to be told about the problem and then go fix it directly.

Then please check the following list of things we ask for in your pull request:

• [x] Have you signed the Eclipse Contributor Agreement, using the same email address as you used in your commits?
• [x] Do each of your commits have a "Signed-off-by" line, with the correct email address? Use "git commit -s" to generate this line for you.
• [x] If you are contributing a new feature, is your work based off the develop branch?
• [x] If you are contributing a bugfix, is your work based off the fixes branch?
• [x] Have you added an explanation of what your changes do and why you'd like us to include them?
• [x] Have you successfully run make test with your changes locally?

In the configuration man page the use_identity_as_username option is mentioned twice (with slightly different descriptions). I think this one is the duplicate / incorrection entry:

https://github.com/eclipse/mosquitto/blob/a8448a9c7b14bdaee6ec80419d43fd6544e789b6/man/mosquitto.conf.5.xml#L1553

When compiling with CMake and MSVC on Windows, both targets mosquitto (mosquitto.exe) and libmosquitto (mosquitto.dll) seem to clash when generating the symbols file mosquitto.pdb.

Both generated binaries mosquitto.exe and libmosquitto seem to consider mosquitto.pdb as their debug symbols file (mosquitto.dll)

Operating System: Windows Build System: CMake Compiler: MSVC Mosquitto version: v2.0.x current development branch, many commits, latest tested: d7833c8dcb0a41a122730c30374bce3740adc7d2

The name clash occurs because the libmosquitto target in ./lib/CMakeLists.txt sets the property OUTPUT_NAME to mosquitto, which implicitly also sets the name of the pdb to mosquitto.pdb.

set_target_properties(libmosquitto PROPERTIES
	OUTPUT_NAME mosquitto
	VERSION ${VERSION}
	SOVERSION 1
	POSITION_INDEPENDENT_CODE 1
)

The solution I found is to set the property PDB_NAME to libmosquitto, as follows:

set_target_properties(libmosquitto PROPERTIES
	OUTPUT_NAME mosquitto
	PDB_NAME libmosquitto
	VERSION ${VERSION}
	SOVERSION 1
	POSITION_INDEPENDENT_CODE 1
)