[Bug]: Error while parsing FromRadio bytes

[bplein]

Category

Other

Hardware

Other

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.6.8, 2.7.0, 2.7.1

Description

While this is an error in the Python CLI, it seems to also affect iOS clients as well. Not reproducible with Web client.

Also reproduced on RAK, Lilygo T-Beam Supreme, and Linux Native nodes.

A while back, I ran into this, and didn't open an issue at that time. I am hitting it again with newer firmware and CLI and client versions.

There is a node in our mesh that seems to be using some odd character code in its short name that causes errors with the CLI. This node does NOT show up in iOS node listing, even though it's in the node and causing these issues via CLI.

The CLI example of the error follows:

meshtastic -t p3n0 --get 0
ERROR file:mesh_interface.py _handleFromRadio line:1264 Error while parsing FromRadio bytes:b'"o\x08\x94\x9d\xec\xcd\t\x12D\n\t!99bb0e94\x12\x05TTT01\x1a\x04T01\xe0"\x06\x80e\x99\xbb\x0e\x94(2B +\t\x0e\x8be\x817\xa1F\x97*v\xed\x89\xa0A\xdf4\'\xc5\xabP\xb9TF\xd0\xed9Q`e\x1c%\x00\x00\x82\xc1-\x9b\x046h2\x15\x08e\x15\x1f\x85\x9f@\x1d\x00\x00\x00\x00%i\xb7\xa2?(\xac\xb6\tH\x02' Error parsing message with type 'meshtastic.protobuf.FromRadio'
Traceback (most recent call last):
  File "/Users/bill/miniconda3/lib/python3.9/site-packages/meshtastic/mesh_interface.py", line 1262, in _handleFromRadio
    fromRadio.ParseFromString(fromRadioBytes)

This error will hit fairly consisently when running a variety of meshatastic CLI commands. It happens over TCP (as shown above), BLE or Serial. Only by using --no-nodes could I be successful running CLI commands.

In the case above, I could go to the webUI and see the node, but couldn't get it from the command line.

I had no way of reaching the user (they are not on our community discord, and I wasn't close enough to message them via Meshtastic), so I deleted the node entry and blocked their incoming packets across all my nodes and went on with life.

Recently I removed them from the block, and the bug is hitting me again.

Let me know if there''s more I can share. Currently blocking them again for the time being.

Relevant log output

[ianmcorvidae]

It's unfortunately pretty hard to fix this. Their shortname, expressed in python bytes as b"T01\xe0", isn't valid utf-8 since e0 can't appear in that encoding, but there's no way to override the interpretation of strings as utf-8 in the python protobuf library, and it doesn't seem to support sending us the actual unicode decoding error, just that DecodeError.

If we can figure out what process is allowing invalid utf-8 to be in shortnames that would maybe be good, possibly in firmware somewhere. Unsure.

[alexl83]

I'm experiencing the same, even with --no-nodes Reaching for my laptop to paste some logs and details

Here's the error, always the same - happening with every command, no matter if it involves nodes or not, when it does, --no-nodes param makes no difference:

some commands which triggered error - serial/BLE makes no difference:

meshtastic --ble --info --no-nodes meshtastic --info --no-nodes && sleep 0.2 && meshtastic --info --no-nodes meshtastic --ch-del --ch-index 1 meshtastic --shutdown meshtastic --reboot

I went and (please don't kill me) asked ChatGPT, which advised to lower python to 3.12 (from 3.13) and ProtoBuf<5, so I did:

pipx uninstall meshtastic
pipx install "meshtastic==2.7.*"
pipx runpip meshtastic install "protobuf<5"

Firmware is 2.7.7.389748e7c from master branch, latest-ish (yesterday's pull)

ERROR file:mesh_interface.py _handleFromRadio line:1297 Error while parsing FromRadio bytes:b'2E\n-Fr' Error parsing message
Traceback (most recent call last):
  File "/Users/alex/.local/pipx/venvs/meshtastic/lib/python3.13/site-packages/meshtastic/mesh_interface.py", line 1295, in _handleFromRadio
    fromRadio.ParseFromString(fromRadioBytes)
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
google.protobuf.message.DecodeError: Error parsing message
ERROR file:stream_interface.py __reader line:195 Error while handling message from radio Error parsing message
Traceback (most recent call last):
  File "/Users/alex/.local/pipx/venvs/meshtastic/lib/python3.13/site-packages/meshtastic/stream_interface.py", line 193, in __reader
    self._handleFromRadio(self._rxBuf[HEADER_LEN:])
    ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/alex/.local/pipx/venvs/meshtastic/lib/python3.13/site-packages/meshtastic/mesh_interface.py", line 1301, in _handleFromRadio
    raise ex
  File "/Users/alex/.local/pipx/venvs/meshtastic/lib/python3.13/site-packages/meshtastic/mesh_interface.py", line 1295, in _handleFromRadio
    fromRadio.ParseFromString(fromRadioBytes)
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
google.protobuf.message.DecodeError: Error parsing message

Restoring a configuration seems to fix things for some time (exporting config is currently not working per #814 ), until it pops up again. Resetting NodeDB has no effect on the error itself

Here's a GPT diagnosis of sorts, which I cannot understand nor say how/if that makes sense

Thanks for the log. It confirms the failure is inside the reader thread while decoding a FromRadio frame, after your command
already returned data. The bytes preview b'2E\n-Fr' is just the first few printable bytes from a chunk the parser thinks is a
protobuf payload—but that payload is not a valid, complete frame. In plain English: the host read loop got out of sync
(missing/extra bytes), so when it tries to parse what it thinks is a message, protobuf throws.

Given your versions (CLI 2.7.1, protobuf 4.25.8, FW 2.7.7) are aligned, this is almost certainly a serial framing/port issue rather than a data-content issue.

[bplein]

It's unfortunately pretty hard to fix this. Their shortname, expressed in python bytes as b"T01\xe0", isn't valid utf-8 since e0 can't appear in that encoding, but there's no way to override the interpretation of strings as utf-8 in the python protobuf library, and it doesn't seem to support sending us the actual unicode decoding error, just that DecodeError.

If we can figure out what process is allowing invalid utf-8 to be in shortnames that would maybe be good, possibly in firmware somewhere. Unsure.

Should this be fixed in the firmware instead? Some client in use is trying to shove in an illegal name (or a one time bug allowed it to be sent). The firmware should filter that out (or is the firmware promiscuous in that it trusts all clients to do the right thing, and doesn't sanitize inputs?)