I'm using an official Espruino MDBT42Q breakout board to try to connect to a BLE enabled video camera. When pairing with a phone a pin is displayed on the screen to bond with the camera.
When I try to connect from the Espruino (running 2v00.120) I get disconnect with code 19 (0x13 BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION) when I execute gatt.startBonding().
I completely understand if this just is not implemented. Just wanted to check if I was missing something.
Hi! It's something that could be added in future firmwares, but I'm afraid it's not in there at the moment...
Ok, I thought that was the case. I'm not familiar with the nRF52 libs but if I find some time I'll see if I can't figure it out and submit a PR.
Won’t this need to be done interactively?
E.g start the pairing and then enter the pin - probably via the console directly into a (new) function call?
I would think so yes. The camera does not show a pin until the bonding is started.
Digging into the docs I found I can change the Peer Manager config io_caps to BLE_GAP_IO_CAPS_KEYBOARD_ONLY and I get a pin to display on the camera when binding.
Then when binding I'm receiving a BLE_GAP_EVT_AUTH_KEY_REQUEST and replying with sd_ble_gap_auth_key_reply to supply the passkey, but so far no love.
This API is new to me so I'll keep digging.
I was using the wrong connection handle. Dumb mistake. It works great now. The additions to the code base are quite minor.
Looks like the device is saving the keys as expected so future connections are secured and the connection is seamless.
So would you guys be interested in me cleaning this up and sending a PR? Is it something you would like to be implemented? If so I think we should decide on how exactly it should work. I would image we would just have the Gatt emit an event on BLE_GAP_EVT_AUTH_KEY_REQUEST and then it would be up to the user to acquire the passkey from the user somehow and submit it back. Right now I just added a gatt.submitPasskey method to the jswrap_bluetooth.c that calls sd_ble_gap_auth_key_reply in bluetooth.c.
Edit: Looks like the encrypted characteristics are working and notifications are working! But now I see that there is no indication implementation and the main characteristic value I need to watch is only readable via indication.
Yes, I'd definitely be interested in adding this - as long as there was a way to do it in such a way that it didn't suddenly start requiring a passkey on normal devices! That could probably be done by enabling the BLE_GAP_IO_CAPS_KEYBOARD_ONLY with a bleStatus flag though.
Hopefully you should be able to do the normal method of queueing a BLEP_ enum which would then emit a NRF.on('passkey_request'...) event.
I guess while we're at it, it might be possible to allow the DISPLAY caps as well... It'd just be another event with a passkey in it.
Real shame about the indications though. They shouldn't be too hard to add in the same way as notifications - there just hasn't been much call for them as there are very few devices that use them. It looks like your camera is particularly strange!
Don't worry about formatting, just type in the text and we'll take care of making sense of it. We will auto-convert links, and if you put asterisks around words we will make them bold.
For a full reference visit the Markdown syntax.
© Espruino, powered by microcosm.
Report a problem