10857 questions

12933 answers

20165 comments

25468 members

0 votes
341 views 5 comments
by
Hello,

I've a RUT955 with FW 00.06.07.4, and I'm using the Internal MQTT broker on port 1883, configured in bridging mode versus an external remote broker for some MQTT topics. The MQTT bridge is configured with QoS 2 and Clean Session false. With this setup everything works very well, also in cases of network down periods, the MQTT broker republish the messages that it saved internally with QoS 2 and I correctly receive them on the remote broker. But I've some questions:

- What is the maximum Queue for MQTT messages to send to the bridge? From my tests, the maximum default queue message with QoS 2 is limited to 100 messages, correct?

- There is any chance to increase this limit? I need to have more buffer in this specific case beacause there are some long network down periods. From my test, I've correctly changed the mosquitto.conf file adding the max_queued_messages with a value of 256. Then, starting mosquitto from CLI with mosquitto -c mosquitto.conf (for testing it), the config file is read properly and the MQTT broker bridge queue growed from 100 to 256 messages, but if i publish 256 messages without network connection, at the moment of reconnection of the bridge, only about 150 messages (sometimes 152, sometimes 150) are sent (more than 100, obvious, but not 256 as specified in the .conf...). From what I know, there is also a memory_limit value in the mosquitto.conf that can be added. From the tests, the RAM usage of mosquitto was about 1.5mb with queue empty, and 2.5-3mb with queue full of 150 messages, it won't go over if I publish other messages for reaching 256 limit, so it seems to be a max RAM allocation problem. Router RAM is about 80% free, so if there is a way to increase "mosquitto dedicated RAM", it will be a possible solution (if this is the problem, from what I think and from my tests).

Thanks in advance for every answer

1 Answer

0 votes
by
Hi,

For now, there are no changes planned for increasing the limits of MQTT within the RUT955 product as there was no demand for it. I will pass this as a suggestion though and let you know if anything comes up.

EB.
Best answer
by
Hi,

Ok, thank you for your answer. But if I want to increase this limit manually like i edited the mosquitto.conf? what file or configuration I need to edit? mosquitto memory_limit variable? other system files to edit? Just for knowing what is the structure and what process or script is limiting it.

Thanks in advance
by
If you want to change your mosquitto config manually, this manual page should explain every option in enough detail:

https://mosquitto.org/man/mosquitto-conf-5.html

EB.
by
The Mosquitto config manual on their website is for the latest version. Mosquitto on RUT955 is an old 1.4.15 version (2018) and some settings are not supported... I've read that the max_queued_messages in the conf file, with 1.4.15 version, are not applied to bridges. Is there a way to update it, for example with opkg? If yes, what is the repository? Also for security reasons, there are a lot of fixed CVE issues...
by
This manual has all the commands, so if you're missing some of them in the config file - then it's not supported with the version we have. Unfortunately, as I said, there are no plans for now on updating and I wouldn't recommend overwriting the current MQTT with opkg, as it might break it to the point where you will have to rollback by restoring the device to defaults.

If you wish to do changes to the firmware yourself, please consider looking at our SDK tools, they will allow you to compile packages into the firmware.

https://wiki.teltonika-networks.com/view/GPL

EB.
by

I've succesfully increased the queue from 100 to 1024 messages setting the max_queued_messages to 1024 and also setting the memory_limit to 10mb (10485760 bytes), both in the mosquitto.conf under etc folder. Everything works, for now, I'm going to test it for some days to check if it is stable. No mosquitto updated version is needed, the 1.4.15 is enough.

These 2 settings of course could be implemented in a future FW release, they could be setted through th WEB GUI, for example. I think it's not a big job adding them but it's quite simple. Thanks for reporting this to your development team.

I also didn't know that there is a SDK for the FW, thanks for the suggestion and for your time. smiley