My Meshtastic node and MeshCore node cannot communicate

My Meshtastic node and MeshCore node cannot communicate

This is one of the most common points of confusion for new mesh users: both Meshtastic and MeshCore run on similar LoRa hardware, operate in the same 915 MHz band, and can even share the same physical channel frequency - yet they cannot exchange messages with each other. Here is why, and what your options are.

Why they are incompatible

Meshtastic and MeshCore are completely independent software stacks. While both modulate data over LoRa radio, they differ in every layer above the physical radio signal:

• Packet format: Meshtastic uses Protocol Buffers (protobuf) serialized payloads inside its own envelope structure. MeshCore uses a different binary packet format with its own header fields, addressing, and payload encoding. A MeshCore node receiving a Meshtastic packet sees garbage bytes it cannot interpret, and vice versa.
• Encryption: Meshtastic encrypts channel traffic with AES (AES-128 or AES-256 depending on the pre-shared channel key length; the default "LongFast" channel uses a short, publicly known key that provides no real privacy). MeshCore uses a different scheme - AES-128 for channel traffic with Curve25519 public keys for direct messages. The two use incompatible key material and algorithms, so even if a node could parse the outer envelope, it cannot decrypt the other's payload.
• Routing logic: Meshtastic uses managed flood routing with hop decrement. MeshCore uses a different routing model oriented around repeater nodes and room servers. The routing metadata fields in each protocol are incompatible.
• Node identity: Meshtastic identifies nodes by a 32-bit node number derived from hardware MAC. MeshCore uses a public-key-based identity system. There is no translation layer between them.

There is no bridge - yet

As of the current date, no production bridge firmware or software exists that can transparently relay messages between a Meshtastic mesh and a MeshCore mesh in real time. Research and community projects have explored the concept, but none have reached a state suitable for general use.

Workarounds for cross-protocol communication

If your community includes both Meshtastic and MeshCore nodes and you need them to share information, the following approaches can help:

• Room server as intermediary: A MeshCore room server is normally a mesh contact reached over RF (or Bluetooth) by selecting it from your contact list - it is not an internet service by default. Some operators bridge a room server to the internet as a separate, non-default and uncommon setup; this is an advanced configuration, not something that works out of the box. Even where such a bridge exists, it only connects MeshCore clients to that room server - it does not let a Meshtastic node join.
• Manual human or gateway relay: The only reliable cross-protocol path today is a human (or a custom script) reading messages off one network and re-posting them on the other. Note that Winlink is not a bridge between Meshtastic and MeshCore: Winlink is an amateur-radio email system that requires a valid amateur radio license and separate HF/VHF gear or an internet connection, and neither Meshtastic nor MeshCore connects to it natively. Do not plan an interop path around Winlink.
• Dual hardware stacks: Deploy two physically separate nodes at the same location - one running Meshtastic and one running MeshCore. A human operator or automated script on a co-located computer can relay messages between the two networks over their respective serial or Bluetooth APIs.

Recommendation

For a new community deployment, choose one protocol and standardize. Mixed-protocol communities incur significant coordination overhead. If you are integrating with an existing regional mesh, match whatever protocol that mesh uses.