Connecting a RAK4631 (WisBlock) to CLI applications MeshTUI via Bluetooth on Linux causes a hard freeze of the node. The device becomes completely unresponsive, fails to transmit, and does not perform an automatic watchdog reboot. A manual hardware reset is required to restore functionality.
Environment:
Hardware: RAK4631 (nRF52840) on WisBlock Base.
Firmware: any MeshCore build
Environment:
- Node Hardware: RAK4631 (nRF52840) / WisBlock Base
- Firmware: Reproduced on Meshtastic and MeshCore
- OS: Ubuntu Linux (Kernel 6.8.0-94-generic)
- BlueZ Version: 5.72
- PC BT Hardware: Intel Corp. Bluetooth wireless interface (ID 8087:0a2a)
- Clients tested: MeshTUI, MeshSense
Clients (hardware) tested: MeshTUI, MeshSense. (with meshtastic)
Steps to Reproduce:
Power the RAK4631 node (running standalone, stable 24/7).
Attempt to connect to the node via Bluetooth using a Linux desktop client (MeshTUI or MeshSense /Windows).
The node freezes during or immediately after the connection handshake/sync.
The node stays in this frozen state until a manual physical reset is performed.
Observed Behavior:
No Automatic Reboot: The internal watchdog fails to recover the node.
Client Specific: This does not happen with the Android/iOS mobile apps, only with Linux-based desktop clients.
Consistency: The issue is reproducible across different firmware versions (Meshtastic and MeshCore).
Expected Behavior:
The Bluetooth connection from a Linux client should not cause a terminal state that requires physical intervention.
Please implement a 'Rate Limiting' or 'Slow Sync' option for BLE connections. Currently, the app sends Protobuf requests too fast for the RAK4631/nRF52840, causing a hard freeze. A configurable delay between requests would fix this.
Connecting a RAK4631 (WisBlock) to CLI applications MeshTUI via Bluetooth on Linux causes a hard freeze of the node. The device becomes completely unresponsive, fails to transmit, and does not perform an automatic watchdog reboot. A manual hardware reset is required to restore functionality.
Environment:
Hardware: RAK4631 (nRF52840) on WisBlock Base.
Firmware: any MeshCore build
Environment:
Clients (hardware) tested: MeshTUI, MeshSense. (with meshtastic)
Steps to Reproduce:
Power the RAK4631 node (running standalone, stable 24/7).
Attempt to connect to the node via Bluetooth using a Linux desktop client (MeshTUI or MeshSense /Windows).
The node freezes during or immediately after the connection handshake/sync.
The node stays in this frozen state until a manual physical reset is performed.
Observed Behavior:
No Automatic Reboot: The internal watchdog fails to recover the node.
Client Specific: This does not happen with the Android/iOS mobile apps, only with Linux-based desktop clients.
Consistency: The issue is reproducible across different firmware versions (Meshtastic and MeshCore).
Expected Behavior:
The Bluetooth connection from a Linux client should not cause a terminal state that requires physical intervention.
Please implement a 'Rate Limiting' or 'Slow Sync' option for BLE connections. Currently, the app sends Protobuf requests too fast for the RAK4631/nRF52840, causing a hard freeze. A configurable delay between requests would fix this.