[Bug]: No channel while trying to send DM

[danditomaso]

Contact Details

Dandcodes

What happened?

I have a friend I DM with frequently, my application was saying I was connected to my Heltec Meshtastic device. Anytime I send a DM the cloud icon shows up, but quickly turns to a cloud with an X through it, and after clicking on it the error says "no channel" which isn't a very helpful as it doesn't describe how I can fix the potential issue.

App Version

2.5.16

Phone

Pixel 6 Android 15

Device

Heltec v3

Firmware

2.5.20

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct

[resunltd]

I have a similar issue using Station G2.
Attempting to send a DM to radios that I have been daily messaging has stopped working. Android APP shows instant cloud with slash indication upon SEND. Both ends showing Green Lock. Other radios in mesh can be DM'd as usual without issue from the G2.

Also tried deleting the nodes to refresh the key.

Any ideas?

[GUVWAF]

If the Android app shows an instant cloud with slash, it's a different issue, e.g. no interface (radio issue) or duty cycle limit reached. The NO_CHANNEL comes from the device you're sending to and should indeed be fixed by deleting the nodes.

You could check the serial logs (use e.g. https://flasher.meshtastic.org/ "Open Serial Monitor") to see where it is complaining about.

[roberthadow]

This is extraordinarily good information.

[garthvh]

This comes directly from the firmware here

firmware/src/mesh/ReliableRouter.cpp

Line 111 in 7eb7727

// Send a 'NO_CHANNEL' error on the primary channel if want_ack packet destined for us cannot be decoded

for a dm if I remember correctly this is a key mismatch.

[resunltd]

Hello Garth,

I appreciate your reply. Can you expand on it a little? Is there a work around?

Regards

[resunltd]

Hello,
This issue is happening when using DM only. Several well used nodes are having this issue. So I just built two new nodes for testing.

Open channel works normally.

I just now flashed two Heltec E-paper units with InkHUD_2.5.20_firmware.factory.bin
They appear to be good. They can send and receive to each other.

One of them sends and receives from other nodes on the mesh and on my desk normally.
The other one sees local nodes on the local mesh and on my desk. However does not receive or transmit messages to them.

Older nodes with this behavior are on the latest Flasher Beta.

All settings are default and look identical on both units.
All tested nodes showing green lock on Android App.

Any idea whats happening?

[EnGamma]

I have also been seeing the instantaneous slash-cloud response to a DM attempt. It has only happened to me on a few occasions for a handful of msg target nodes (out of several dozen) and in each case, I believe the problem went away in a few hours without any intentional action to fix it, maybe sooner. My most recent example was sending from a Lillygo-TLora-v2.1-1.6. I am running 2.5.23 Alpha fw. DMs to other nodes works normally, where normal is a slash-cloud response takes a second or more to show. I don't think what I'm seeing is a duty-cycle-exceeded issue because my nodes are lightly loaded.

[Starblade42]

Did you solve your issue?

I my case, the problem started after I had to re-flash one of my nodes. I had made a bad config option and was forced to wipe and re-flash. I presume this meant I generated a new PKI pair on this node.

After that, the two nodes I had (one iOS and one Android) could no longer communicate, and had the "no channel" error next to any sent DMs.

I couldn't communicate from my newly-flashed iOS paired T1000e to my other, Andoid-paired T1000e, or visa-versa.
In the Node List on the Android node, I pressed "remove" on the iOS paird T1000e to force it to forget the old PKI. On the iOS paired node, I pressed "delete" on the android node from the node list to force it to forget that Android PKI.

A minute or so later they showed back up in the node lists, since there are physically within range, and I was able to send DM messages again.

If this is what's needed every time a node has a new PKI key, that's pretty bad. This procedure requires coordination from both ends to force it to forget the old PKI key and start fresh, even though they should be capable of reading the new PKI information, right?

Anyhow, I hope this helps someone else.!

[TheLikesOfMeh]

DUDE, this is exactly the same problem I was having and the simple method you described was the fix!! Thank you for sharing!

[fluffrider]

Having same issue...do I just give the radio time to sync into the network? Super frustrating that I am getting a no channel after I flashed it. Makes me really hesitant to add more nodes, as there are separated by 10s of miles.

[garthvh]

If you are getting a no channel error the PKI key has not been exchanged with the node you are trying to DM, or that node has rolled out of the nodedb.

[resunltd]

Is there a way to "force" a PKI key exchange?

I am still having issues with nodes unable to send DM's to each other. It's been going on for at least 2 weeks. I can't seem to clear the issue and "start fresh."
All the nodes in question were working fine for months until I updated my Android App to 2.5.21
Reverted back to 2.5.20 and have been waiting a week for the errors to clear with no change.
I get the Cloud with Slash immediately upon sending a DM, also the Locks show Green in the App.
What can be done? Please advise. Thank you.

[fluffrider]

If you are getting a no channel error the PKI key has not been exchanged with the node you are trying to DM, or that node has rolled out of the nodedb.

I even Reset the NodeDB. Still not working. Hope it sorts itself. Or something?? I don't want to reset all my nodes and not be able to communicate with others on the established network.

[resunltd]

I tried a Node DB reset as well with no change. I would really like to see a definitive method for a solution to this issue. At least a clear work around if nothing else. I have 15 nodes up in a 50+ node mesh and I am concerned what would happen with a future FW update.

[garthvh]

Resetting the node db starts the clock over again and is not a way to solve the no channel routing error.

[fluffrider]

It was working before I flashed it with a software update. Will it “heal” itself? Or forever it will be without the proper pki key? On Apr 21, 2025, at 10:25 AM, Garth Vander Houwen ***@***.***> wrote: If you are getting a no channel error the PKI key has not been exchanged with the node you are trying to DM, or that node has rolled out of the nodedb. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[resunltd]

I have been trying to fix this for two weeks or more. Previously keys would "sort themselves out." Usually in a matter of minutes to hours.

Software changes seem to have changed how updated nodes are handled. Very confusing IMO.

[killer-booper]

I have see this many times as well. My fix has been to delete LF and add it back with AQ== key. Might be something to do with primary channel setting after flashing.

[killer-booper]

I have see this many times as well. My fix has been to delete LF and add it back with AQ== key. Might be something to do with primary channel setting after flashing. Then resetting the node DB on both or removing that node. When this occurs I can message on LF and get a check mark but it never actually goes anywhere.

[kozzae]

I have the same " no channel " crap !! The nodes I used to talk to don't work anymore, tried all the usual fixes but some of them still don't talk !? Is there a new and easy fix for this ?

[Starblade42]

Remove each other from your node lists and then try to DM them again. I had two devices that wouldn't talk. I deleted node 1 from node 2's list of DMs and removed node 2 from node 1's list of DMs and then tried messaging them again. That fixed it.

[spitfire]

Remove each other from your node lists and then try to DM them again. I had two devices that wouldn't talk. I deleted node 1 from node 2's list of DMs and removed node 2 from node 1's list of DMs and then tried messaging them again. That fixed it.

trying to delete a conversation from DM list crashes the current iOS app ;)

[kozzae]

Hi Jonathan That worked for some of them but the stations I’m trying to reconnect with are all 20km away ! They are discreetly deployed so that makes it harder to go there and play radio ! Doh ! So I’d need to delete nodes on both sides and wait till they reappear in my node list before I can try a DM again and maybe they will shake hands ! ThanksColin On 29 Jun 2025, at 10:30, Jonathan Huff ***@***.***> wrote: Remove each other from your node lists and then try to DM them again. I had two devices that wouldn't talk. I deleted node 1 from node 2's list of DMs and removed node 2 from node 1's list of DMs and then tried messaging them again. That fixed it. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[Starblade42]

• Yes! This is VERY frustrating and problematic functionality for the nodes to cling to the old key despite there being a new one. We really need to get this fixed with a way to pick up the new key without needing physical access to delete them from both sides. How can you tell the remote to do that when your DMs can't be delivered because of this problem? AARGH

[garthvh]

• Yes! This is VERY frustrating and problematic functionality for the nodes to cling to the old key despite there being a new one. We really need to get this fixed with a way to pick up the new key without needing physical access to delete them from both sides. How can you tell the remote to do that when your DMs can't be delivered because of this

Sounds like you are using DMs for testing instead of traceroutes, for DMs to be secure the keys changing needs to be tracked, and if it changes both sides need to know.

[sendingstrings]

What config change needs to occur in order for a remote node to treat your node as a new node?

[kozzae]

Yous are the guys with the brains here ! Not me ! lol Yeah did notice the trace route still works tho & yeah I do use for testing but nice to message and get a response message back from the ones that have stopped working Is there a Bluetooth repeater that could be used on our nodes ? As the range is sometimes not good and lots of houses here in oz have metal roofs if node is on roof then sometimes a problem to connect On 29 Jun 2025, at 10:52, Jonathan Huff ***@***.***> wrote: Yes! This is VERY frustrating and problematic functionality for the nodes to cling to the old key despite there being a new one. We really need to get this fixed with a way to pick up the new key without needing physical access to delete them from both sides. How can you tell the remote to do that when your DMs can't be delivered because of this problem? AARGH —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[fluffrider]

Nothing has worked for me. About to reflash everything On Jun 28, 2025, at 7:52 PM, Jonathan Huff ***@***.***> wrote: Yes! This is VERY frustrating and problematic functionality for the nodes to cling to the old key despite there being a new one. We really need to get this fixed with a way to pick up the new key without needing physical access to delete them from both sides. How can you tell the remote to do that when your DMs can't be delivered because of this problem? AARGH —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[kozzae]

What do you know about the frequency slots ?

[kozzae]

What I would like to know is, is it possible to say set up a Channel slot say 45 as your primary private channel but have the standard LongFast as secondary channel ?

[jschrempp]

No you can not. Each node's radio is set for one slot. The slot is either set manually or set to 0 so that the firmware picks the appropriate slot. When set to 0 the firmware uses the Name of the primary channel (channel 0) to determine the frequency slot.

[kozzae]

Ok on a new subject , now I've never looked at it
But wondering if the blue screen from a heltec V3 would fit on the heltec T114 board ? As I have a fried V3 , screen should still work , does anybody know ? Or is that just a dumb question lol

[mrbreitkreutz]

Same issue, needed to completely reset both devices and delete the app and reinstall. Very problematic for reconnecting to other mesh devices particularly if remote

[kozzae]

Hopefully someone will know ? So on my RF50 xio seeed I can't get it to come up with DFU so that it programs (using chrome on win11 ) I also have a 1000e tracker think I ordered the wrong one mines is a lorawan can it be re flashed to work Meshtastic ??

[garthvh]

Not compatible with meshtastic, only the T1000E

[kozzae]

So this Lorawan tracker 1000e cannot be programmed with Meshtastic ?

[garthvh]

So this Lorawan tracker 1000e cannot be programmed with Meshtastic ?

Does it have 2 or 4 magnetic pins? Only the 4 pin e model works with meshtastic.

[kozzae]

Hiya it has 4 pins either side of the magnets

[kozzae]

Don't know how it goes into DFU mode ? Just don't wanna play !

[sendingstrings]

Same with 2.7.3

[sendingstrings]

Still happening with 2.7.3 with DMs. Channels and traceroute both work fine.

This key issue should either resolve automatically, or be fixable from only one end. Maybe with a prompt after a no-channel error.

[dem1tris]

Agree. There should be human-friendly warning about changed keys (like in the ssh). And the error itself must be less cryptic.

[TMTwatch]

I'm having this issue on 2.5.17. I have tried all the steps above expect re-flashing both devices.

[killer-booper]

I have see this many times as well. My fix has been to delete LF and add it back with AQ== key. Might be something to do with primary channel setting after flashing. Then resetting the node DB on both or removing that node. When this occurs I can message on LF and get a check mark but it never actually goes anywhere.

[mecworks]

How about a way to force a new key exchange if you know you're talking to a trusted node? i.e. I have several nodes talking to each other with the exception of one that has this no channel error. I know and trust the remote node. Why can't I just say, re-exchange keys. SSH does something similar when a remote host's keys change. I you know about that and trust it, you can refresh the keys.

[llamafilm]

If you trust the remote node, you can delete it from your NodeDB and recreate it. That's similar to the SSH behavior you describe.

That's different than the remote node trusting you. With SSH, you prove your identity by providing a key. If you rotate your key, the SSH server will not accept the new one. You must first login with the old key to tell it to trust the new key.

[korbinianbauer]

If you trust the remote node, you can delete it from your NodeDB and recreate it

Sure, but how do I know I have to do that?

Node A is getting the error message (Delivery failed), but Node B has to fix the issue by deleting Node A.

Node A cannot communicate the issue to Node B directly though (except via a common channel).

What I'd like to see is Node B getting a notification like

A node that claims to be !457475 tried to send you a DM, but uses an untrusted signature.

Do you want to trust the new signature?

If you rotate your key, the SSH server will not accept the new one

That's not the analogy we're talking about here, we're talking about the SSH server rotating keys. The analogy has limits, because both sides are both server and client here.

[llamafilm]

Ok I misunderstood you before, I thought you were suggesting it would be automatic, which is a security risk. A notification and prompt to approve is a good idea, I agree.

[llamafilm]

A more accurate error message would help users understand what's happening and how to fix it. I posted in #10210 a few days ago but I'll rewrite it here because it's essentially the same issue.

When a node receives a PKI DM with want_ack that it cannot decrypt, it currently NAKs with NO_CHANNEL. This commonly happens when it still has the sender’s old public key after they rotated. This is confusing and is easy to misinterpret because it sounds like a channel/PSK problem.

I propose adding a new Routing.Error enum called PKI_DECRYPT_FAILED and using it in ReliableRouter in this case instead of NO_CHANNEL. Then phone clients can display that as a more friendly message, perhaps with some suggestion that the remote node needs to delete you from its DB. Before I make a PR for this, I'd like to hear if it would be welcome.

[DarkRanger935]

 While appreciating the fact that in the vast majority of cases you are correct regarding benign causes, I’d suggest there is a fundamental issue with trying to oversimplify user prompts when it comes to PKI. The problem with covering the message with oven mitts as described is that the error can also be caused by a 3rd party attempt at a spoofing or replay attack…The whole point of PKI is to prevent exactly that sort of thing. It’s purely a security infrastructure, including messages. Are the majority of users familiar with the intricate details of PKI and the impacts of related config changes? Of course not. There is a reason pki and other security-focused functions (kerberos is a good example) keep it clinical and throw you technical messages or error codes that have to be looked up by people that understand “under the hood.”. You dont *know* if it is a benign problem or malignant security issue without looking into the details and context. You might be able to get away with assumptions (Oversimplification) 99.9% of the time, but that .1% might be a painful (if not preventable) event. On Apr 24, 2026, at 00:21, Elliott Balsley ***@***.***> wrote:  A more accurate error message would help users understand what's happening and how to fix it. I posted in #10210<#10210> a few days ago but I'll rewrite it here because it's essentially the same issue. When a node receives a PKI DM with want_ack that it cannot decrypt, it currently NAKs with NO_CHANNEL. This commonly happens when it still has the sender’s old public key after they rotated. This is confusing and is easy to misinterpret because it sounds like a channel/PSK problem. I propose adding a new Routing.Error enum called PKI_DECRYPT_FAILED and using it in ReliableRouter in this case instead of NO_CHANNEL. Then phone clients can display that as a more friendly message, perhaps with some suggestion that the remote node needs to delete you from its DB. Before I make a PR for this, I'd like to hear if it would be welcome. — Reply to this email directly, view it on GitHub<#6079?email_source=notifications&email_token=BW3AWNVYB6V5QVRUK53IYML4XMIYRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRWHE3TSOJUUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FMMZXW65DFOJPWG3DJMNVQ#discussioncomment-16697994>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BW3AWNTVMQ3CXFCCC22UPCL4XMIYRAVCNFSM6AAAAABXKOKYZGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNRZG44TSNA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[llamafilm]

Your point is valid regarding the UI suggestion. But what do you think about the proposal to change the enum to PKI_DECRYPT_FAILED instead of NO_CHANNEL ? That's not a simplification; I'd say the current message is inaccurate or misleading at best.

[DarkRanger935]

Honestly, I don’t know the protocol enough to make an informed opinion on that; but if i had to guess, i’d say it sounds good provided the change is innocuous to users On Apr 24, 2026, at 07:42, Elliott Balsley ***@***.***> wrote:  Your point is valid regarding the UI suggestion. But what do you think about the proposal to change the enum to PKI_DECRYPT_FAILED instead of NO_CHANNEL ? That's not a simplification; I'd say the current message is inaccurate or misleading at best. — Reply to this email directly, view it on GitHub<#6079 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BW3AWNW5ORYFOUQOKPGJJH34XN4MHAVCNFSM6AAAAABXKOKYZGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNZQGI4TGNQ>. You are receiving this because you commented.Message ID: ***@***.***>