Same thing happened to me. Had to delete the node. Not from the freshly installed device (because that one is already cleaned out) but from all other devices. Once that was done they all message.
Interesting, thanks!
There was a guy recently that i wanted to echange some message with, but we were forced to use the public channel because private messages did not work.
I will suggest him to reset his node-db. And i will do that on my other remote nodes. So far i avoided this, because it always deleted the fixed postion entries, most annoying…
Hopefully that is the only issue.
I’m living in a place where the landscape allows excellent communication over several square km and i’m operating some nodes that greatly contribute to the mesh.
During the time of 2.4.x the node list filled up after a reset to 100+ nodes after half a day. Since 2.5.x i’m just getting about 60 nodes after a day or so. Hopefully this does not means that a number of people were getting tired of endless forced updating and left the project :-/
imo, here’s no way there are 60 nodes in range unless you’re in CHOP or some urban hellscape like that…or getting crapped up with MQTT.
Yep.
I just re-flashed the nodes I was experimenting with back to the known-good firmware. This is too much of a time sink for me to mess with at this juncture. I keep saying I’m about to put all this Chinesium junk up for sale and put the money toward some MeshRiders, or something professional that actually works most of the time. I know it’s an open source hobby project and I’m getting what I’m paying for (though the donations in equipment and money I’ve put out to several people are not insignificant when totaled up). I should just call it a learning experience and move on, but I always seem to circle back to messing with it again like a dog to his vomit…
You could just delete the single nodes you are trying to comm with instead of the full database.
And this is really equal?
Well all you are trying to do is release the old psk. So if you factory reset your node it will have new public and private key. So if the node you are trying to talk with does not have the new keys there will be a problem. So resetting node db will do the trick but also just deleting the single node with new keys on the receiving device should also fix the issue.
1 Like
Uuh, yes, that’s another thing. I already lost the ability to remote administer a node because the public key has changed and it seems impossible to set it manually to the old value.
All right, i will have an eye on that node-db or single node reset. Will report then…
you can’t put the admin key in remotely. This is good from a security standpoint, but a real pain in the ass from a logistical perspective if you already have nodes deployed in places you can’t easily access. basically you’re hosed until you visit each node and connect to it directly and paste the key from the master node (the one you will use to administer with) into the slave node.
It looks like this is actually the solution. Today i updated my last of several remote nodes to 2.5.6
Call it node B. The node i’m carrying with me all the time is node A. B is a RAK4631 and A is my TBeam. I deleted the node-db just before the update. Afterwards i was able to communicate from A to B and vice versa. Then i drove back to another location where ii cannot reach B. Fortunately i installed node C (another RAK4631) in the forest. It can easily reach A from that location and also B! So i wanted to write a message from A to B via C. And there i got the NAK, the crossed cloud symbol. Probably because C got the old psk(?) from B when B was still running 2.4.2. Now i’ve done a node-db reset on C (via the new admin channel) and after the reboot i suddenly was able to get an ACK from B via C. So here, deleting the node-db seemed to be essential.
The problem ist that probably many others struggled with that problem and some of them got tired with such problems that were not documented properly. Or did i miss something?
I’ll see whether issues can be resolved by the same trick when getting the next NAK. Then i need to tell the communication partner via the public channel what to do…
I’m going to mark the problem as solved here in that thread. Thank for the constructive discussion.
PS: Another big advantage of 2.5.x is that a fixed position is now NOT deleted when doing a node-db reset! Another detail people were waiting for… 
1 Like
Thanks so much for raising this. Doing a node DB reset was missing in my testing of my nodes and it seems to have helped my Store & Forward functionality.