Unable to Communicate with Node Via Meshtastic CLI

[amaxwellnsa1]

I hope I'm posting in the correct location. Having some trouble using the python CLI on a linux machine.

Linux Distro: Void Linux

uname -a
Linux HOSTNAME 6.6.58_1 #1 SMP PREEMPT_DYNAMIC Wed Oct 23 16:39:51 UTC 2024 x86_64 GNU/Linux

I've never had issues with this on Debian based distro's. Any who, esptool is able to communicate and successfully flashes firmware just fine via usb/serial "/dev/ttyACM0"

However meshtastic refuses to connect to the USB serial connection. I've tried various methods to communicate with the node. It does seem to work via hostname/IP , but not via serial.

meshtastic -s /dev/ttyACM0 --info --debug
DEBUG file:__main__.py common line:1154 Not logging serial output
DEBUG file:serial_interface.py __init__ line:47 Connecting to /dev/ttyACM0
DEBUG file:stream_interface.py __reader line:151 in __reader()
DEBUG file:stream_interface.py _sendToRadioImpl line:114 Sending: want_config_id: 404783841
DEBUG file:stream_interface.py _sendToRadioImpl line:119 sending header:b'\x94\xc3\x00\x06' b:b'\x18\xe1\x85\x82\xc1\x01'
Traceback (most recent call last):
 File "/home/USER/.local/bin/meshtastic", line 8, in <module>
   sys.exit(main())
            ^^^^^^
 File "/home/USER/.local/share/pipx/venvs/meshtastic/lib/python3.12/site-packages/meshtastic/__main__.py", line 1918, in main
   common()
 File "/home/USER/.local/share/pipx/venvs/meshtastic/lib/python3.12/site-packages/meshtastic/__main__.py", line 1194, in common
   client = meshtastic.serial_interface.SerialInterface(
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 File "/home/USER/.local/share/pipx/venvs/meshtastic/lib/python3.12/site-packages/meshtastic/serial_interface.py", line 65, in __init__
   StreamInterface.__init__(
 File "/home/USER/.local/share/pipx/venvs/meshtastic/lib/python3.12/site-packages/meshtastic/stream_interface.py", line 55, in __init__
   self.connect()
 File "/home/USER/.local/share/pipx/venvs/meshtastic/lib/python3.12/site-packages/meshtastic/stream_interface.py", line 79, in connect
   self._waitConnected()
 File "/home/USER/.local/share/pipx/venvs/meshtastic/lib/python3.12/site-packages/meshtastic/mesh_interface.py", line 861, in _waitConnected
   raise MeshInterface.MeshInterfaceError(
meshtastic.mesh_interface.MeshInterface.MeshInterfaceError: Timed out waiting for connection completion

exact same when I run "meshtastic -s /dev/ttyACM0 --info"

however when I run: "meshtastic --noproto"
I seem to get output:

meshtastic --noproto
WARNING file:mesh_interface.py _sendToRadio line:959 Not sending packet because protocol use is disabled by noProto
Connected to radio
DEBUG | ??:??:?? 1041 [Power] Battery: usbPower=1, isCharging=1, batMv=4208, batPct=100

it does seem to be a little less busy than I've seen on these devices before, But I'm not certain if that's just because there's not much network activity at the moment.

Here's the output of "meshtastic --support"

If having issues with meshtastic cli or python library
or wish to make feature requests, visit:
https://github.com/meshtastic/python/issues
When adding an issue, be sure to include the following info:
 System: Linux
   Platform: Linux-6.6.58_1-x86_64-with-glibc2.39
   Release: 6.6.58_1
   Machine: x86_64
   Encoding (stdin): utf-8
   Encoding (stdout): utf-8
 meshtastic: v2.5.4
 Executable: /home/user/.local/bin/meshtastic
 Python: 3.12.7 CPython GCC 13.2.0

and this behavior doesn't seem to change between the two nodes I've been able to test with:

lilygo tlora v2.1-1.6
heltec v3

The only real difference I can see between this and my raspberry pi is the python version: (pi is 3.11.2) and the CPython GCC (pi's is 12.2.0)

I'm hoping someone has some direction for me. My apologies if I'm not in the right place here. I just figured posting an "issue" would place blame on the code here, which I'm really not confident is the problem here. Being new to this distribution (and loving it so far), I'm sure it's possible Ive messed something up here.

Thank you in advanced.

[amaxwellnsa1]

I see that I was using -s instead of --port, here's a corrected command and output:

meshtastic --port /dev/ttyACM0 --info --debug
DEBUG file:__main__.py common line:1154 Not logging serial output
DEBUG file:serial_interface.py __init__ line:47 Connecting to /dev/ttyACM0
DEBUG file:stream_interface.py __reader line:151 in __reader()
DEBUG file:stream_interface.py _sendToRadioImpl line:114 Sending: want_config_id: 2237846479
DEBUG file:stream_interface.py _sendToRadioImpl line:119 sending header:b'\x94\xc3\x00\x06' b:b'\x18\xcf\xa7\x8b\xab\x08'
Traceback (most recent call last):
  File "/home/USER/.local/bin/meshtastic", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/home/USER/.local/share/pipx/venvs/meshtastic/lib/python3.12/site-packages/meshtastic/__main__.py", line 1918, in main
    common()
  File "/home/USER/.local/share/pipx/venvs/meshtastic/lib/python3.12/site-packages/meshtastic/__main__.py", line 1194, in common
    client = meshtastic.serial_interface.SerialInterface(
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/USER/.local/share/pipx/venvs/meshtastic/lib/python3.12/site-packages/meshtastic/serial_interface.py", line 65, in __init__
    StreamInterface.__init__(
  File "/home/USER/.local/share/pipx/venvs/meshtastic/lib/python3.12/site-packages/meshtastic/stream_interface.py", line 55, in __init__
    self.connect()
  File "/home/USER/.local/share/pipx/venvs/meshtastic/lib/python3.12/site-packages/meshtastic/stream_interface.py", line 79, in connect
    self._waitConnected()
  File "/home/USER/.local/share/pipx/venvs/meshtastic/lib/python3.12/site-packages/meshtastic/mesh_interface.py", line 861, in _waitConnected
    raise MeshInterface.MeshInterfaceError(
meshtastic.mesh_interface.MeshInterface.MeshInterfaceError: Timed out waiting for connection completion

[kop316]

It looks like the serial port never gets an awknlowldgement from the device, which can mean one of two things:

1. You are in the dialout group, so it's a permissions issue (https://meshtastic.org/docs/software/python/cli/usage/#permission-denied-devttyusb0 ) , or
2. The serial output of the device is not enabled.

[mariotti]

From the error messages you never got actually connected.

Check @kop316 suggestion.

An other simple one is the connecting cable. Try to change the USB cable. did you use the same cable?

Also try to run as root.

Then you can check what you see with "lsusb" commands.

Let us know how it goes.

A+

[amaxwellnsa1]

Thanks for your responses! My apologies for the delay in responding as I've been away.

lsusb output:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 004: ID 04f2:b217 Chicony Electronics Co., Ltd Lenovo Integrated Camera (0.3MP)
Bus 002 Device 008: ID 147e:2016 Upek Biometric Touchchip/Touchstrip Fingerprint Sensor
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 006: ID 1a86:55d4 QinHeng Electronics USB Single Serial
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

second to last device is our guy.

I've run this as root as well as as user, the issue exists across two devices I'm administering with void being the common denominator between meshtastic CLI not functioning.

Here's user groups:
USER : USER wheel floppy dialout audio video cdrom optical kvm xbuilder

Meshtastic CLI functions fine with the same node and cable via a Raspbian based machine. which makes me almost certain this portion of physicals is fine.

also I'll mention again that the esptool flashes firmware onto the nodes just fine. via the affected systems. and it's only the meshtastic CLI itself that for whatever reason fails to communicate through /dev/ttyACM0 and seemingly only via serial. tcp connections seem to function perfectly fine. (not able to confirm bluetooth)

now that it's been some time I'll try to update software and my python environments and see if this didn't work itself out in the software repositories. My suspicion is that it's something on the python or kernel side of the equation (I almost always find a way to absolutely destroy my python libs anyways)

I did run strace here back after I initially posted here. and recall noting that it seemed to be calling the expected kernel modules...(comparing the output of the nonfunctional voidlinux meshtastic environment, VS the functioning raspbian meshtastic environment) I didn't record my results as this is over my head, but I'm wanting to say that it seemed that it was not recieving the same responses after prompting the serial device. so maybe there's some kernel compatibility issues here (a shot in the dark though as I'm no source of knowledge on this topic or voidlinux for that matter.)

Man I thought I had already posted this... oh well, Might was well update this comment:

Go figure... after getting my software updated (xbps-install -Su) and getting a new VENV setup:

uname -a
Linux HOSTNAME 6.6.60_1 #1 SMP PREEMPT_DYNAMIC Mon Nov 11 21:45:58 UTC 2024 x86_64 GNU/Linux

(meshtastic-venv) [USER@HOSTNAME bin]$ meshtastic --port /dev/ttyACM0 --info
Connected to radio

Owner: XXXXXXXXXXXXXXX
My info: { "myNodeNum": 145559000, "rebootCount": 5, "minAppVersion": 30200 }
Metadata: { "firmwareVersion": "2.5.6.d55c08d", "deviceStateVersion": 23, "canShutdown": true, "hasWifi": true, "hasBluetooth": true, "positionFlags": 811, "hwModel": "TLORA_V2_1_1P6", "hasPKC": true, "hasEthernet": false, "role": "CLIENT", "hasRemoteHardware": false }

seems to be working fine :/

Either the void team fixed it or ya'll did... I still don't really know what was actually breaking it. But I'll take the win. (it will eat at my soul eternally not knowing what was actually broken) The other machine should still have it's python environment and I may try to figure out what specifically it was as long as the owner hasn't messed with any of that since we were working on it last.

Thanks for the follow up. and I'll try to let you know if I can narrow down what specifically corrected this behavior.

[mariotti]

Happy it worked!!!

About python libs I share common frustration ;) But java is not any better ;)

About narrowing down the issue, I'd suggest not to spend that time.
Use it to make something new working!

A+
F