[Feature Request] Ability to remotely change public key of a repeater

[michaeljaddy]

Not sure if this is even technically possible but on our small mesh in Yorkshire we seem to have run into an issue where we have 2 repeaters and they both have the same 2 characters at the start of the public key which appears to be causing some odd routing decisions.

It would be great if there was a way to change the public key without having to physically visit remotely deployed node.

[marrold]

Import / Export of the key would also be useful

[mrlmuk]

Does this public key match actually cause an issue? Wont both nodes receive if they are within range and process the message because it matches the key with no knowledge of the other?

The keys can already be imported and exported via a switch in the firmware, you just need to edit and compile a special version. If you want to export the key from something without that option, first install the companion firmware.

[michaeljaddy]

Does this public key match actually cause an issue? Wont both nodes receive if they are within range and process the message because it matches the key with no knowledge of the other?

The keys can already be imported and exported via a switch in the firmware, you just need to edit and compile a special version. If you want to export the key from something without that option, first install the companion firmware.

I believe it is causing me issues with being able to log in to a repeater I remotely manage but I could be wrong. At the moment I only have a single path out of my node into the rest of the mesh - via the red circled repeater at the bottom. That repeater has an adjacency to two other repeaters both prefixed with "ec", so I never know if it taking the blue path or the green path. I own the repeater on the left and frequently have difficulty logging in despite good signal strength - so I can only assume the other repeater is replying first saying "invalid password" before I manage to get logged in to mine.

Even if it's not the cause of that particular issue it's still a pain for running traces etc as I can't force it down a particular path.

[mrlmuk]

That's a good example which hopefully the devs can test or already know the answer to.

I would have though when logging in the full credentials (pubkey and password) are encrypted with the public key so only the device with the private key could open the message, see its ID and then check the cleartext password. Others would not even see its own public ID so it would not reply to the wrong password.

I will try and keep my second device just to the south east of you as repeater more often as well, if you can reach it.

[trisweb]

This is pretty important. As a mesh scales being able to ensure we have good prefixes for routing is a big limitation on further growth. I'm sure Seattle knows it, and Boston is running into it now too.

We don't need a perfect solution, as in automatic resolution or an improved routing approach or 3 chr prefixes; right now we need practical ability to easily fix the issue when it comes up.

Just being able to upload a new private key and reboot the node would be more than enough.