PAN1026, using the SDK, EasySPP, and connection-key
I'm not sure how to ask this question. I think my problem is related to the connection-key, but here goes...
I am using the EVAL_PAN1026 Evaluation Kit that has two dongles. Using the SDK, I wrote a TestApp (Windows PC) to run one dongle. I am using EasySPP to run the other dongle. After jumping through some SDK hurdles, and getting some help from this Forum (thanks Michael), I was able to get the TestApp working. The TestApp configures the dongle to be discoverable, and to automatically accept incoming connections. EasySPP connects/disconnects/reconnects all day long with the TestApp.
Leaving the TestApp running, I shut down EasySPP back to the desktop. Then I restart EasySPP, and again it reliably connects/disconnects/reconnects with the TestApp. That's all good. I noted, however, that when I fired it back up, it remembered the connection-key from before shutting it down.
Doing the same with the TestApp (to simulate what our product will be doing, power-cycle, changing battery, next day usage, etc), I shut down the TestApp, and brought it back up again. Of course, the TestApp re-inits the PAN1026, and sets it back up again from scratch, i.e. there's no stored/remembered key.
My problem: Now EasySPP takes TWO connection attempts to establish the initial connection after the TestApp restarted. The first attempt never seems to complete (there isn't any sort of error indication) on either EasySPP or TestApp, although there were packet-exchanges. Note that I did not restart EasySPP, I simply left it in the Disconnect state from the last time it connected. Re-clicking the EasySPP Connect button a second time works, and everything is fine from then on.
So I think my problem is related to EasySPP's idea of the old connection key and the TestApp no longer having the same key. I noted that EasySPP remembers the link-key from previous sessions. If I click the "Clear" button on EasySPP and then connect, it always works the first time, but...
Is there something the TestApp should be doing/sending to tell the other end that it needs a new key?
I have attached a log-file for the initial connection attempt from both EasySPP and the TestApp. The logs do not show the second-click of the EasySPP Connect button.
If it matters, in bt_application_mng_capability_callback() I am setting:
*io_capability = TCU_MNG_NO_INPUT_NO_OUTPUT;
Thanks for the help.
Hello Jeff Jones,
*io_capability = TCU_MNG_NO_INPUT_NO_OUTPUT;
This is for the Secure Simple Pairing (SSP). With the above setting, the device that the PAN1026 is in it, will notify (as initiator or a responded) that it has no way to show or enter a passkey...
Keys, Link Keys in particular which are the essence of the Pairing (they are used to secure the line) need to be stored. I will elaborate about that.
This is the part that tells which level of security (in a simplified way) of the SMP is needed to be turn on or off, in this case --> No need for MITM (Man In The Middle
Since you set the *io_capability = TCU_MNG_NO_INPUT_NO_OUTPUT; you opted to Just Works level of authentication in the SSP. Even if "just works" is used for pairing, security keys are exchanged. These keys, if stored in the EEPROM (se mentioned earlier) can be used for a later connection. In other words, you will not need to exchange keys again and again and any future connection will take faster.
What if you do not store the keys, and went through a reset:
If the remote device tries to re-connect, he will use the security keys from the old connection...
- PAN1026 will ask the host processor for the keys.
- If these are not supplied by the host (because they were not stored...)
- The connection is declined by the PAN1026, on the grounds of 'we need to pair first...' with a matching error code.
- At this point, it is up to the remote device to re-try the connection by triggering a new pairing. Then the pairing is done and the keys are exchanged again.
As long as the power is stays on, or no reset these keys are available...
Since the task to store the keys is assigned to the host, the SDK makes no assumption as for how many keys, and where the keys are stored. It will just forward the request to the host via the key_store_api.h.
In theory the host processor could store the keys anywhere it likes: flash memory, hard disk, whatever. It just needs to implement the key store API.
Thank you for your response.
Hmmm... I think you're saying the whole thing boils down to the key management. Okay, I think I'm starting to see the light, so I will focus on the keys for the next few questions.
But first, a side note: I noticed in those attached logs, the TestApp does NOT receive what the EasySPP sent to it! Looking at the Tx of EasySPP on one side, and the Rx of the TestApp on the other, they do not correlate! After a lot of experimentation (and attempting to find a bug that wasn't there), I replaced my TestApp with another instance of EasySPP running on the other dongle (two instances of EasySPP talking to each other). I can exactly recreate those logs by:
- EasySPP-A connects to EasySPP-B.
- EasySPP-A disconnects.
- EasySPP-B clears its Link Key by clicking on the "Clear" button.
- Before the next step, clear the logs on both EasySPP instances.
- EasySPP-A reconnects (attempts to) to EasySPP-B; it won't connect.
- ... and we get the same log output (Tx/Rx byte sequences) as was attached.
So, on the one hand, this validates that my TestApp is probably working correctly (minus the key management), but on the other hand, because the logs do not correlate, this implies that Windows (or maybe it's EasySPP somehow) is doing something behind the scenes, does it not?
Back to the keys: In our product's environment, we have a Windows PC running Apps that use standard Windows Bluetooth API connectivity calls, and we have our device with the PAN1026 that always awaits incoming connections. Our device never initiates a connection. I'm not even sure what questions to ask next, but here goes:
Who sources the key for the connection, the PC or the device? Isn't it true that the key comes from the PC because the device has been previously discovered/paired and is listed in the PC's Devices and Printers Control Panel (Win7) or the Bluetooth Devices (Win10)?
If the device doesn't have the key, or lost it due to a reset, does this always require re-pairing from the PC to get a new key?
This one's a biggie - What's the difference between the key (as we have been discussing) and a PIN, and a Passkey? I note that when Adding New Device to the PC's Settings/Control Panel, it didn't ask for a PIN - but with our old device (different Bluetooth chip) it did.
About the SDK: If the device has no I/O, i.e. TCU_MNG_NO_INPUT_NO_OUTPUT, should bt_api_connection_request_confirm() be called from within the bt_application_mng_connection_request_callback()? I think the answer is yes because that's what I'm doing and it seems to be working, but I note that nowhere in the SDK is that the case because the demo-Apps always prompt for Input from a user, which we don't have. If it should NOT be called from within the bt_application_mng_connection_request_callback(), then when/how should it be called?
Thank you so much for your help.
I'm very sorry - this forum is for the wireless connectivity products from Panasonic Industrial devices, like Bluetooth modules that can be integrated into products to make them Bluetooth-aware.
This is a different Panasonic - you are looking for the consumer electronics division of Panasonic.
Unfortunately I don't know how that division handles customers requests like yours.