Environment: Ubuntu Linux with bluez, Meshtastic T3S3 on firmware 2.7.26, meshtastic CLI 2.7.8 from pip.
Repro
Step one. Pair and trust the node from the host, entering the PIN shown on the device screen:
bluetoothctl pair AA:BB:CC:DD:EE:FF
bluetoothctl trust AA:BB:CC:DD:EE:FF
Step two. Disconnect cleanly and reboot the machine, or let the node go to sleep.
Step three. Run the CLI:
meshtastic --ble name_or_address --info
The CLI reports "No Meshtastic BLE peripheral with identifier or address '...' found" (also seen as "Timed out waiting for connection completion"), and --ble-scan comes back empty. Meanwhile bluetoothctl info AA:BB:CC:DD:EE:FF shows "Connected: yes".
What I think is going on
This is the one-slot trap, not an adapter problem. Meshtastic nodes allow a single BLE connection and stop advertising while connected (single connectable advertising instance in src/nimble/NimbleBluetooth.cpp). bluez defaults to ReconnectMode=global, which silently reconnects bonded devices after a reboot or power event and never lets the slot go. Result: the node is connected-but-invisible. The CLI scan only sees advertising nodes, and this one isn't advertising.
Even published Linux guides run into it. This write-up (https://dustinrue.com/2025/12/connecting-to-a-meshtastic-node-using-bluetooth-from-linux/) hits the same behavior ("bluetoothctl staying connected to the node when it shouldn't have") and its advice is to reboot the machine, which works but masks the cause. As far as I can tell nobody has written down the mechanism, so it keeps catching people.
Workaround (verified)
In /etc/bluetooth/main.conf, under the General section, add:
ReconnectMode=none
then run:
systemctl restart bluetooth
The node stays free ("Connected: no") until a client actually connects, and the CLI connects normally.
Suggestion
The CLI already prints helpful hints for "BLE device not found", in the DEVICE_NOT_FOUND error handling block: Bluetooth disabled / deep sleep / out of range. A Linux-specific bonded auto-reconnect bullet would have saved me an afternoon. If a hint like that would be useful, I'm happy to open a small PR — a "Device is bonded and Bluetooth auto-reconnected (Linux/bluez)" bullet plus a bluetoothctl disconnect / ReconnectMode=none tip.
Environment: Ubuntu Linux with bluez, Meshtastic T3S3 on firmware 2.7.26, meshtastic CLI 2.7.8 from pip.
Repro
Step one. Pair and trust the node from the host, entering the PIN shown on the device screen:
bluetoothctl pair AA:BB:CC:DD:EE:FF
bluetoothctl trust AA:BB:CC:DD:EE:FF
Step two. Disconnect cleanly and reboot the machine, or let the node go to sleep.
Step three. Run the CLI:
meshtastic --ble name_or_address --info
The CLI reports "No Meshtastic BLE peripheral with identifier or address '...' found" (also seen as "Timed out waiting for connection completion"), and --ble-scan comes back empty. Meanwhile bluetoothctl info AA:BB:CC:DD:EE:FF shows "Connected: yes".
What I think is going on
This is the one-slot trap, not an adapter problem. Meshtastic nodes allow a single BLE connection and stop advertising while connected (single connectable advertising instance in src/nimble/NimbleBluetooth.cpp). bluez defaults to ReconnectMode=global, which silently reconnects bonded devices after a reboot or power event and never lets the slot go. Result: the node is connected-but-invisible. The CLI scan only sees advertising nodes, and this one isn't advertising.
Even published Linux guides run into it. This write-up (https://dustinrue.com/2025/12/connecting-to-a-meshtastic-node-using-bluetooth-from-linux/) hits the same behavior ("bluetoothctl staying connected to the node when it shouldn't have") and its advice is to reboot the machine, which works but masks the cause. As far as I can tell nobody has written down the mechanism, so it keeps catching people.
Workaround (verified)
In /etc/bluetooth/main.conf, under the General section, add:
ReconnectMode=none
then run:
systemctl restart bluetooth
The node stays free ("Connected: no") until a client actually connects, and the CLI connects normally.
Suggestion
The CLI already prints helpful hints for "BLE device not found", in the DEVICE_NOT_FOUND error handling block: Bluetooth disabled / deep sleep / out of range. A Linux-specific bonded auto-reconnect bullet would have saved me an afternoon. If a hint like that would be useful, I'm happy to open a small PR — a "Device is bonded and Bluetooth auto-reconnected (Linux/bluez)" bullet plus a bluetoothctl disconnect / ReconnectMode=none tip.