Eclipse Mosquitto - An open source MQTT broker

Overview

Eclipse Mosquitto

Mosquitto is an open source implementation of a server for version 5.0, 3.1.1, and 3.1 of the MQTT protocol. It also includes a C and C++ client library, and the mosquitto_pub and mosquitto_sub utilities for publishing and subscribing.

Links

See the following links for more information on MQTT:

Mosquitto project information is available at the following locations:

There is also a public test server available at https://test.mosquitto.org/

Installing

See https://mosquitto.org/download/ for details on installing binaries for various platforms.

Quick start

If you have installed a binary package the broker should have been started automatically. If not, it can be started with a basic configuration:

mosquitto

Then use mosquitto_sub to subscribe to a topic:

mosquitto_sub -t 'test/topic' -v

And to publish a message:

mosquitto_pub -t 'test/topic' -m 'hello world'

Documentation

Documentation for the broker, clients and client library API can be found in the man pages, which are available online at https://mosquitto.org/man/. There are also pages with an introduction to the features of MQTT, the mosquitto_passwd utility for dealing with username/passwords, and a description of the configuration file options available for the broker.

Detailed client library API documentation can be found at https://mosquitto.org/api/

Building from source

To build from source the recommended route for end users is to download the archive from https://mosquitto.org/download/.

On Windows and Mac, use cmake to build. On other platforms, just run make to build. For Windows, see also README-windows.md.

If you are building from the git repository then the documentation will not already be built. Use make binary to skip building the man pages, or install docbook-xsl on Debian/Ubuntu systems.

Build Dependencies

  • c-ares (libc-ares-dev on Debian based systems) - only when compiled with make WITH_SRV=yes
  • cJSON - for client JSON output support. Disable with make WITH_CJSON=no Auto detected with CMake.
  • libwebsockets (libwebsockets-dev) - enable with make WITH_WEBSOCKETS=yes
  • openssl (libssl-dev on Debian based systems) - disable with make WITH_TLS=no
  • pthreads - for client library thread support. This is required to support the mosquitto_loop_start() and mosquitto_loop_stop() functions. If compiled without pthread support, the library isn't guaranteed to be thread safe.
  • uthash / utlist - bundled versions of these headers are provided, disable their use with make WITH_BUNDLED_DEPS=no
  • xsltproc (xsltproc and docbook-xsl on Debian based systems) - only needed when building from git sources - disable with make WITH_DOCS=no

Equivalent options for enabling/disabling features are available when using the CMake build.

Credits

Mosquitto was written by Roger Light [email protected]

Master: Travis Build Status (master) Develop: Travis Build Status (develop) Fixes: Travis Build Status (fixes)

Issues
  • Raspbian Stretch install error

    Raspbian Stretch install error

    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: [email protected]:/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.

    opened by Obo666 82
  • Unable to connect to Mosquitto 1.4.10 over Websocket

    Unable to connect to Mosquitto 1.4.10 over Websocket

    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 [email protected] 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

    opened by manavkumarm 47
  • Segfault using Mosquitto websockets

    Segfault using Mosquitto websockets

    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 ([email protected]=0x6268e0 <int_db>, [email protected]=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 ([email protected]=0x6268e0 <int_db>, [email protected]=0x1ca3a20, [email protected]=2, [email protected]=6) at loop.c:378
    #12 0x0000000000404b36 in main (argc=<optimized out>, argv=<optimized out>) at mosquitto.c:385
    
    opened by wiebeytec 44
  • High latency (~40 ms) when sending successive messages in a row - missing TCP_NODELAY

    High latency (~40 ms) when sending successive messages in a row - missing TCP_NODELAY

    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: image


    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.

    opened by verybadsoldier 40
  • Unable to create PID file

    Unable to create PID file

    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

    opened by joekerna 33
  • Still Websockets support not available

    Still Websockets support not available

    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

    opened by AdamMiltonBarker 33
  • Websocket connections are not accepted after docker images update to eclipse-mosquitto:1.5.3 or eclipse-mosquitto:1.5

    Websocket connections are not accepted after docker images update to eclipse-mosquitto:1.5.3 or eclipse-mosquitto:1.5

    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
    
    Type: Bug Component: mosquitto-broker 
    opened by sergey-lukin 32
  • After upgrade to fix OpenSSL vulnerability websockets have stopped working

    After upgrade to fix OpenSSL vulnerability websockets have stopped working

    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

    opened by AdamMiltonBarker 31
  • Broker process running, but not accepting connections

    Broker process running, but not accepting connections

    Hi,

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

    [email protected]:~$ 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
    
    [email protected]:~$ 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

    [email protected]:~$ lsb_release -a
    No LSB modules are available.
    Distributor ID:	Ubuntu
    Description:	Ubuntu 15.04
    Release:	15.04
    Codename:	vivid
    

    Mosquitto conf

    [email protected]:~$ 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

    [email protected]:~$ 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.

    Type: Bug Component: mosquitto-broker Status: Blocked 
    opened by kumar003vinod 30
  • Add unix domain socket listener.

    Add unix domain socket listener.

    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) #

    opened by toast-uz 29
  • docker eclipse-mosquitto:2.0 Error: Address not available

    docker eclipse-mosquitto:2.0 Error: Address not available

    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

    opened by a-wing 27
  • connect_async and loop_start order matters when no network connection.

    connect_async and loop_start order matters when no network connection.

    If I start my client like this without a network connection then once the connection is available the client will connect and be happy. The problem is if I call mosquitto_disconnect then reconnect later calling init() again, I don't get a connect callback.

    void init() {
        mosquitto_loop_start(mosq);
        mosquitto_connect_async(mosq);
    }
    

    If I start my client like this without a network connection then it doesn't automatically connect when the network becomes available:

    void init() {
        mosquitto_connect_async(mosq);
        mosquitto_loop_start(mosq);
    }
    

    So to auto-connect correctly and still get a callback when called a second time, I have to do this:

    void init() {
        mosquitto_loop_start(mosq);
        mosquitto_connect_async(mosq);
        mosquitto_loop_start(mosq);
    }
    

    This works in both scenarios for some reason even though the second mosquitto_loop_start returns MOSQ_ERR_INVAL. This doesn't makes sense to me because it looks like the second mosquitto_loop_start shouldn't do anything except return the error. https://github.com/eclipse/mosquitto/blob/v2.0.14/lib/thread_mosq.c#L42

    Mosquitto Version: 2.0.14 OS: Linux Ubuntu 20.04

    opened by andrewwade 0
  • mosquitto_disconnect stops the network loop but mosquitto_connect doesn't start it.

    mosquitto_disconnect stops the network loop but mosquitto_connect doesn't start it.

    This is more of an unexpected behavior on my part and maybe I just haven't found the right documentation.

    I assumed I could call the following sequence and the client would just resume running the loop after the second connect.

    mosquitto_loop_start(mosq);
    mosquitto_connect_async(mosq);
    sleep(10);
    mosquitto_disconnect(mosq);
    sleep(10);
    mosquitto_connect_async(mosq);
    sleep(10);
    mosquitto_loop_stop(mosq);
    

    But instead, I have to call mosquitto_loop_start again after mosquitto_disconnect. Otherwise I won't get the connect callback on the second mosquitto_connect_async.

    I believe it's because of the following lines: https://github.com/eclipse/mosquitto/blob/master/lib/loop.c#L297-L298 https://github.com/eclipse/mosquitto/blob/master/lib/loop.c#L320-L321

    Mosquitto Version: 2.0.14

    opened by andrewwade 0
  • Subscribe with QoS=0 and packet identifier 0 incorrectly rejected

    Subscribe with QoS=0 and packet identifier 0 incorrectly rejected

    Mosquitto 2.0.14 rejects a subscribe command that has QoS=0 and Packet Identifier = 0. Looking at section 2.3.1 of the mqtt 3.1.1 spec (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html) it says:

    SUBSCRIBE, UNSUBSCRIBE, and PUBLISH (in cases where QoS > 0) Control Packets MUST contain a non-zero 16-bit Packet Identifier [MQTT-2.3.1-1].

    Notice the "in cases where QoS > 0". Apologies if I'm missing some other part of the spec that states that packet ID of 0 is always invalid (I have old clients that use it and that have worked fine for years with mosquitto pre-V2).

    Reproduction. The first command shows the failure, the second one shows a successful subscription. The only difference is a packet id of 0 vs. 1 in the subscribe command.

    > echo -en '\x10\x21\x00\x04MQTT\x04\x00\x00\x00\x00\x15HEATMAT-deaddead-1234\x82\x12\x00\x00\x00\x0dsystem/offset\x00' | nc -q 2 ncore 1883 | od -x
    0000000 0220 0001
    0000004
    > echo -en '\x10\x21\x00\x04MQTT\x04\x00\x00\x00\x00\x15HEATMAT-deaddead-1234\x82\x12\x00\x01\x00\x0dsystem/offset\x00' | nc -q 2 ncore 1883 | od -x
    0000000 0220 0001 0390 0100 0000
    0000011
    

    The first example results in an error in the mosquitto log of "Client HEATMAT-deaddead-1234 disconnected due to malformed packet."

    Mosquitto 2.0.14 on Manjaro Linux

    opened by tve 0
  • Latest versions on the 1.6.x release line not available even in mosquitto-dev PPA

    Latest versions on the 1.6.x release line not available even in mosquitto-dev PPA

    None of the recent 1.6.x versions higher than 1.6.9 are available for the Ubuntu 20.04 version. Even after adding the mosquitto-dev PPA to the repository list, only the latest 2.0.x version was available and not the latest ones on the 1.6.x line.

    Here are the available package versions after adding the mosquitto-dev PPA:

    $ apt-cache policy mosquitto
    mosquitto:
      Installed: 1.6.9-1
      Candidate: 2.0.14-0mosquitto1~focal1
      Version table:
         2.0.14-0mosquitto1~focal1 500
            500 http://ppa.launchpad.net/mosquitto-dev/mosquitto-ppa/ubuntu focal/main amd64 Packages
     *** 1.6.9-1 500
            500 http://in.archive.ubuntu.com/ubuntu focal/universe amd64 Packages
    

    OS version details:

    Operating System: Ubuntu 20.04.4 LTS
    Kernel: Linux 5.13.0-51-generic
    Architecture: x86-64
    
    opened by albinsuresh 0
  • Fuzzer support

    Fuzzer support

    Signed-off-by: Arjun Singh [email protected]

    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.
    • [ ] If you are contributing a new feature, is your work based off the develop branch?
    • [ ] 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?

    Fuzzer Support in mosquitto, for Security.
    In future, i will add mosquitto in oss-fuzz
    
    I would really like to hear your thought on harness aka fuzzer.c file
    
    opened by 0x34d 0
  • OnConnect() Callback does not execute using mosquitto in C program

    OnConnect() Callback does not execute using mosquitto in C program

    The following code works perfectly in Raspberry Pi but not in Windows 10. However, when "mosquitto_loop_start" function is changed to "mosquitto_loop_forever" function it works, but it's not convenient for me. Is there someone who can help me to deal with this problem?

    I thank you in advance

    mqtt_sub.zip

    opened by aekzitouni 0
Eclipse Paho MQTT C++ Client Library

Eclipse Paho MQTT C++ Client Library This repository contains the source code for the Eclipse Paho MQTT C++ client library on memory-managed operating

Eclipse Foundation 614 Jun 16, 2022
New generation message broker service

Push1st Push1st is open source multiple protocol PUB/SUB message broker server (Pusher, MQTT, RAW WebSocket). Key features Suitable for distributed on

Naveksoft 16 Jan 18, 2022
Mongoose Embedded Web Server Library - a multi-protocol embedded networking library with TCP/UDP, HTTP, WebSocket, MQTT built-in protocols, async DNS resolver, and non-blocking API.

Mongoose - Embedded Web Server / Embedded Networking Library Mongoose is a networking library for C/C++. It implements event-driven non-blocking APIs

Cesanta Software 8.5k Jun 29, 2022
A portable MQTT C client for embedded systems and PCs alike.

MQTT-C is an MQTT v3.1.1 client written in C. MQTT is a lightweight publisher-subscriber-based messaging protocol that is commonly used in IoT and net

Liam Bindle 500 Jun 22, 2022
Control Hörmann doors drives directly via MQTT from Home Assistant

hoermann_door Control Hörmann doors drives directly via MQTT from Home Assistant

null 54 Jun 20, 2022
An MQTT-based Virtual Wall for ESP8266 Devices and Gerber files to make the IR hat; this code and board can easily be adapted to be ANY infrared controller/remote!

Roomba-Virtual-Wall-ESP8266-MQTT An MQTT-based Virtual Wall for ESP8266 Devices I made this based off of the IRSend, IRremoteESP8266, and EspMQTTClien

null 8 Sep 20, 2021
WiFi/MQTT Code For the ThingPulse ESPGateway

ESP32-Paxcounter with ThingPulse ESPGateway This project lets you run the ESP32-Paxcounter project on the ThingPulse ESPGateway. The ESPGateway has tw

Daniel Eichhorn 5 Dec 18, 2021
Wifi MQTT Data Logging via an esp8266 for the Ikea VINDRIKTNING PM2.5 air quality sensor

MQTT connectivity for the Ikea VINDRIKTNING This repository contains an ESP8266 firmware, which adds MQTT to the Ikea VINDRIKTNING PM2.5 air quality s

Sören Beye 847 Jun 24, 2022
This is a MQTT-enabled, compact weather station powered by a Wemos D1 minicontroller and built with 3D-printed parts

This is a MQTT-enabled, compact weather station powered by a Wemos D1 minicontroller and built with 3D-printed parts. It supports OTA updates.

65397 1 Feb 10, 2022
Show pressure & temperature readings from Home Assistant/MQTT on a mini display

home-assistant-barometer-display A mini Home Assistant display to show pressure & temperature readings (and made to look pretty with 'freeform pcb' br

David Barton 4 Jan 4, 2022
AWS FreeRTOS MQTT demo project running on the NXP i.MXRT1050-EVKB.

AWS MQTT demo example project Click to import in Keil Studio Cloud: Board: NXP IMXRT1050-EVKB The tables below list the device configuration for this

Arm - Keil tools 1 Oct 18, 2021
Use an esp32 as gateway for the Eqiva Bluetooth smart lock to integrate it in Home Assistant as MQTT lock

esp32-keyble-homeassistant Use an esp32 as gateway for the Eqiva Bluetooth smart lock to integrate it in Home Assistant as MQTT lock Based on the grea

null 7 Apr 28, 2022
RPI Pico WIFI via ESP-01S, LWESP, FreeRTOS, and MQTT example

RPIPicoRTOSMQTT RPI Pico WIFI via ESP-01S, LWESP, FreeRTOS, and MQTT example Demo code for RPI Pico using ESP-01S for wifi connection over uart. With

Dr Jon Durrant 2 Dec 2, 2021
Google IOT MQTT Sample

This is an adaptation of Zephyr's Google Cloud IoT Core MQTT sample samples/net/cloud/google_iot_mqtt for the nRF9160-DK, using modem features to offload certificate storage, TLS and JWT calculation.

Jeffrey Urban 5 Jan 27, 2022
AirGradient Pushing to InfluxDB or MQTT

Custom AirGradient Sketch AirGradient’s sensor set up is a good base and reasonably affordable. This Arduino sketch allows you to integrate with a loc

null 8 Apr 6, 2022
16 Channel Current Meter to MQTT Gateway

16 Channel Current Meter to MQTT Gateway This sketch runs on an ESP8266 and reads data from 16 Channel Current Measurement Module over RS485 Modbus an

null 4 Jan 11, 2022
RakNet is a cross platform, open source, C++ networking engine for game programmers.

RakNet 4.081 Copyright (c) 2014, Oculus VR, Inc. Package notes The Help directory contains index.html, which is full help documentation in HTML format

Facebook Archive 3.1k Jun 20, 2022
An easy to use and powerful open source websocket library written in C.

libwebsock Easy to use C library for websockets This library allows for quick and easy development of applications that use the websocket protocol, wi

Jonathan Hall 46 May 4, 2022
Zyre - an open-source framework for proximity-based peer-to-peer applications

Zyre - Local Area Clustering for Peer-to-Peer Applications Linux & MacOSX Windows Contents Overview Scope and Goals Ownership and License Using Zyre B

The ZeroMQ project 791 Jun 23, 2022