# 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.