[Bug]: MQTT on Large Topics Locks App Processes and Radio.

[djblueshift]

Category

Other

Hardware

Heltec V3

Is this bug report about any UI component firmware like InkHUD or Meshtatic UI (MUI)?

• Meshtastic UI aka MUI colorTFT
• InkHUD ePaper
• OLED slide UI on any display

Firmware Version

2.7.19.bb3d6d5 and earlier

Description

When MQTT is active on a large region eg "msh/US", devices lock up due to receiving and trying to decode an endless stream of incoming packets that have no matching channel/PSK on the node.
I understand WHY this happens but when this happens, i can no longer access any settings (no way to turn MQTT off) on the app (nor can the node send RF messages out) as it is tied up trying to decode undecodable packets. The only fix is a reflash or disabling MQTT via CLI.

Some thoughts on possible resolution,
-detect that a lot of undecodable packets are incoming and rate limit past a certain point so app commands can get through and process
-maybe a notification advising the user that this is due to a large MQTT root topic being set
-MQTT on/off menu option on node itself?

Relevant log output

INFO | 00:04:29 278 [NimbleBluetooth] Received MQTT topic msh/US/2/e/LongFast/!b7158542, len=50

WARN | 00:04:29 278 [NimbleBluetooth] No suitable channel found for decoding, hash was 0x0!

DEBUG | 00:04:29 278 [NimbleBluetooth] NimbleBluetooth: handling ToRadio packet, fromPhoneQueueSize=1

DEBUG | 00:04:29 278 [NimbleBluetooth] Got MqttClientProxy message

INFO | 00:04:29 278 [NimbleBluetooth] Received MQTT topic msh/US/2/e/LongFast/!e73e97e9, len=50

WARN | 00:04:29 278 [NimbleBluetooth] No suitable channel found for decoding, hash was 0x0!

DEBUG | 00:04:29 279 [NimbleBluetooth] NimbleBluetooth: handling ToRadio packet, fromPhoneQueueSize=1

DEBUG | 00:04:29 279 [NimbleBluetooth] Got MqttClientProxy message

INFO | 00:04:29 279 [NimbleBluetooth] Received MQTT topic msh/US/2/e/LongFast/!5fc4f0eb, len=50

WARN | 00:04:29 279 [NimbleBluetooth] No suitable channel found for decoding, hash was 0x0!

[github-actions]

@djblueshift, Welcome to Meshtastic! 👋

Thanks for opening your first issue. If it's helpful, an easy way
to get logs is the "Open Serial Monitor" button on the Web Flasher.

If you have ideas for features, note that we often debate big ideas
in the discussions tab
first. This tracker tends to be for ideas that have community
consensus and a clear implementation.

We're very active on discord,
especially the #firmware and #alphanauts-testing channels. If you'll
be around for a while, we'd love to see you there!

Welcome to the community! ❤️

[github-actions]

Please provide device logs to better understand the issue. You can collect logs by using the Web Flasher or Meshtastic CLI as follows: For Web Flasher logs, go to https://flasher.meshtastic.org, connect the device via USB, click Connect, open the device console/log output, reproduce the problem, and then copy/download and attach/paste the logs. For Meshtastic CLI logs, run: meshtastic --port --noproto, reproduce the problem, and then copy/paste the terminal output. Additionally, please confirm the steps to reproduce the issue, and mention if there are any specific expected vs actual outcomes.

[benseidler01]

I also experienced this yesterday with my RAK WisMesh Wifi Gateway after updating the firmware to 2.7.19. I believe I upgraded from the factory firmware version of 2.5.?. I was able to access and configure the device from the web tool, connecting via serial. In the minutes after enabling MQTT on device for my local MQTT server (I did not even connect to the public server) the ability to configure my device was lost. I could still connect to the admin stuff from the web took via serial, but i could not load any of the settings pages under radio config, device config, or Module config. I was planning to reflash the device but I have not yet done that, if there are any specific things you would like me to help troubleshoot with before I do that. I am completely unable to manage the device in its current state, however the nodes and messages functionality within the navigation window are still functional. Let me know if you need anything from this device in the current state before I reflash it. I also want to note that my internal MQTT server is not busy at all, as I am only beginning to build out this framework. I am in the middle of nowhere and there are not many meshtastic devices in the vicinity at all. I don’t think it is related to the volume of traffic from MQTT...

[djblueshift]

@benseidler01 what does the serial monitor show for you? Any similar messages like I received: "No suitable channel found for decoding, hash was 0x0!"