Using CoreScope to Trace Packets

CoreScope is our network analyzer. For a tour of everything it does, see CoreScope in the Newbie Guide. This page is narrower: it shows you how to use CoreScope to answer one question when something is broken.

Where did my message actually go?

That is the question that turns a guess into a diagnosis. If you can see your packet in CoreScope, you know your radio transmitted and the mesh heard it. If you cannot, the problem is on your end and you can stop looking at the network.

Contents

Step 1: Find Your Public Key Prefix

Your node is identified in packet logs by the first few bytes of its public key. To find yours:

From the CLI:

get public.key

Note the first 2 to 4 hex characters.

From the app: check your node's identity or settings screen.

Step 2: Search for Your Packets

Go to scope.inwmesh.org, open the Packet Browser, and filter on your pubkey prefix over a time range that covers when you had the problem.

You will see the adverts, messages, ACKs and path responses associated with your node. If nothing appears at all, that is itself the answer — your node is not transmitting, or it is transmitting on the wrong frequency. Go check get radio against 910.525,62.5,7,5.

Step 3: Trace a Single Packet

Click any packet to expand it. You get:

From this you can tell whether your advert made it past the first repeater, which link in a path is weak, and whether a message was ever acknowledged.

Use the RSSI and SNR reference tables to judge whether a given hop is healthy or marginal.

Diagnosing Specific Problems

"My messages send but never get acknowledged"

  1. Filter for your pubkey around the time you sent the message.
  2. Find the TXT_MSG (type 0x02) packets.
  3. Did any repeaters hear it? How many hops did it travel?
  4. If it vanishes after one or two hops, the path broke there. Note the last repeater that heard it.
  5. Now search for packets from the destination node at the same time. Did they try to send an ACK that also got lost? A broken return path looks identical to a broken outbound path from where you are sitting, and this is how you tell them apart.

"Nobody can find me"

  1. Send a flood advert from the app.
  2. Within a few minutes, search CoreScope for ADVERT (type 0x04) packets from your pubkey.
  3. Which repeaters heard it? Did it get relayed beyond the first hop?

If your advert reaches one or two nearby observers and goes no further, suspect, in order:

"I can hear the mesh but I cannot send"

  1. Search CoreScope for any packet from your pubkey. Nothing at all means you are not getting out.
  2. Check get radio against the network settings.
  3. Try a zero-hop advert. If the zero-hop shows up in CoreScope but a flood advert never propagates, the nearest repeater is down or misconfigured, and the problem is not yours.

"Is that repeater actually working?"

  1. Search CoreScope for the repeater's pubkey prefix.
  2. Is it receiving? Is it forwarding?
  3. Receives but no forwards means set repeat off, or it is duty-cycle throttled.
  4. Nothing at all means it is offline, on the wrong frequency, or its antenna has failed.

A Word on Observer Coverage

CoreScope only knows what its observer nodes hear. An observer is a passive MeshCore node that reports every packet it receives back to the CoreScope backend. Ours is in Spokane.

This matters for troubleshooting: if you are in an area with no observer nearby, CoreScope may show an incomplete picture of your traffic, and an absent packet does not necessarily prove it was never sent. Weigh CoreScope evidence alongside what your own node and nearby repeaters report.

If you would like to host an observer node and improve coverage for your part of the network, ask in Discord.

Next: Common Scenarios puts these tools together into step-by-step walkthroughs.