It is was a significant hurdle for me during initial install to figure out the pairing code for BLE, even after I read the instructions (no screen on my device). And I am a software developer and had all the tools/skills required.
Would it make sense to provide an option to use “Just works” pairing?
I am also curious what is the motivation for Meshtastic requiring elevated security? Most commercial GPS trackers (inReach/Spot) use “Just works”…
I saw something about that here. Though I have never tried it.
@mc-hamster might be able to elaborate further.
You’re right, it’s not well documented.
Here’s the PR. There are comments in the PR on how this works.
The default pin is 123456
I see, But I guess I was proposing a different solution: with “Just works” authentication no input is expected from the keyboard - it is not less secure than hard coded pin and much more convenient for the user.
1 Like
There’s a discussion in the PR were @beardywalrus wanted to protect against Man-In-The-Middle attacks, so some protection from purely pinless authentication was written.
There’s something there about double-clicking the button within 30 seconds of the authentication request. Maybe that would work for you? I have not tried that.
I see, looks like people are concerned about headless routers security. In this case requiring click on a device maybe gives some additional security (in my opinion it does not, but I’m not an expert.). I’ll check if double click works.
1 Like
It wasn’t a perfect solution. “Just works” would allow anyone within range to connect, or force disconnection of an existing connection. “Just Works” effectively just sets the passcode to all zeros under the hood. With the default passcode, MITM attacks are slightly mitigated (at least it’s not all zeros, you’d have to brute force or know about the project). Double-clicking the button in a headless configuration means at least you have physical access to the device, rather than just driving by. Again, it’s not perfect, but does provide at least proof you have physical access.
Happy to make some changes if anyone wants.
2 Likes
“Just works” protocol does not preclude bonding, so forcing disconnection from a bonded (aka paired) phone should not happen, even if the bonded phone goes away. So I think we are talking about protection during the period of time when the device is first turned on until it is bonded with a (hopefully legitimate) phone. I agree, if somebody is worried about this, having non-default password and button-click is helpful.
BTW, just tried the double-click, it works! Thanks, @beardywalrus!
What were the steps you used? Did you have a display? What board did you use?
This is exciting! This would help a lot of other people. 
1 Like
Steps are simple: when it asks to pair with the device, double-click the middle button on the device and use “123456” as secret code. Repeat if it doesn’t work.
I was using the tbeam V1.1 board w/o screen
I somewhat cheated while I was testing by looking at the debug output from the device, as it is hard to tell whether the double-click was registered properly by the device - the button is so tiny and my fingers are so fat 
I needed to repeat it several times…
Oh, that is pretty easy. Rad, thanks!
Maybe we can double flash the LED to acknowledge that the double click happened. That’ll give a visual indication that the double click worked. Hmm …
I added a few lines to blink the LED when the button is double clicked. This will give you feedback that the double clicked was done successfully. It’ll be in the next build.
3 Likes
@mc-hamster – this is a really helpful addition. would it be worthwhile to update documentation of this new functionality as well?
1 Like
Im building a project and having this really helped.
2 Likes