Server/Client callback completeness and parity

[axa88]

Im just getting started with migrating some very old esp32 Bluetooth peripheral code to NimBLE Arduino v2.x. But I'm confused on what appears to be a new limitation during bonding.

Why is it that the NimBLEServerCallbacks do not at least share the same callbacks regarding pair/bond/security?
For as can been seen in this reference from Nordic chart attached, the initiator/central, and responder/peripheral, could have any combination of capabilities. So, for example in the case where a peripheral is set to only keyboard, and the remote central has a Just Display, or even Keyboard and Display, or even LE Secure Connections enabled, the negotiated method should require the peripheral to enter the displayed passkey by the initiator, and get some sort of notification on what it needs to do.

In this lib implementation, presumably that is the onPassKeyEntry callback, which is what's missing on NimBLEServerCallbacks. And inversely the onPassKeyDisplay callback missing from the Client object for the same reasoning.

Also, from what i recall this chart mirrors what the Bluetooth specification indicates, so regardless, it appears to me that both 'Display' and 'Entry' callbacks should be present (and functional) for both the Server and client i suppose.

[axa88]

So Ive now implemented the library and believe I can confirm some problems with the pairing/bonding functionality of this library...

As a test the peripheral IO capability to BLE_HS_IO_KEYBOARD_ONLY using the values available by referencing esp_gap_ble_api.h which in turn references the ble_hs.h...

So in this example, when the Android client/central initiates a pair/bond, as I speculated nothing but the onConnect callback is triggered. Though i dont know what it would trigger as no callback seems appropriate to indicate the client is displaying the pk.

And this is also true when the io mode is set to BLE_HS_IO_DISPLAY_ONLY, here id be expecting an appropriate callback indicating that the initiator is waiting for the pk to be displayed by our device, perhaps triggering onPassKeyDisplay, but again only the onConnect callback is triggered and nothing else.

What does appear to work, so far, in some regard is both BLE_HS_IO_DISPLAY_YESNO and BLE_HS_IO_KEYBOARD_DISPLAY io modes, for at least when LE Secure Connections is enabled, these should and do trigger the onConfirmPassKey callback as id suspect. Yet it shouldn't when LE Secure Connections isn't enabled but still does so that's doesn't seem right either..

So I may well be missing something fundamental, but so far it seems like these callbacks do not and cannot accurately indicate the proper security modes when triggered by an initiator.

Proper guidance would be appreciated.

[h2zero]

The initiator/client normally would be the one to input the key, while the peripheral/server displays it. I have not seen any case where the initiator/client would display the key, so that is not in the callback set for the client class and vice versa for the peripheral/server.

In this library the security/pairing process is either initiated manually in the application after a connection is made if desired or when the client tries to read/write a characteristic which requires security in which case the process starts automatically.

[axa88]

The initiator/client normally would be the one to input the key, while the peripheral/server displays it.
I have not seen any case where the initiator/client would display the key, so that is not in the callback set for the client class and vice versa for the peripheral/server.

yes, sure it may well be the more popular application indeed, not arguing that. Though im quite sure the chart is correct and we could find that this limitation is not described in the Bluetooth specification.

So I present to you the first case... as I indeed I have an application where the peripheral only has a limited number of hardkeys for entry as there is no opportunity for display and there is the potential for many devices to be in the same location and to be paired at once so simply a confirmation would be confusing.

But now its my intent to build a new ble peripheral emulator to help implementation a parallel ble client framework to BLE specifications. For that it would be required to emulate all valid scenarios. I'm aware that this might be a situation to use a more professional development tool chain, but as a mobile developer im kind of limited in my embedded ability and thus choice of tooling.

In this library the security/pairing process is either initiated manually in the application after a connection is made if desired or when the client tries to read/write a characteristic which requires security in which case the process starts automatically.

Yes, but the problem with not implementing the specification correctly is that it leaves no possibility for the application to control whether securing the connection or not. Again, this might not be the popular implementation, but absolutely within the specification and something done before.

Anyway, I suppose you might now understand the incompatibility with spec, and it would be great if there were a way to better adhere to the flexibility the specification provides.

fwiw my quick estimate assumes fixing this fortunately could be additive rather than subtractive to the current api definition.

[h2zero]

Yes, but the problem with not implementing the specification correctly is that it leaves no possibility for the application to control whether securing the connection or not. Again, this might not be the popular implementation, but absolutely within the specification and something done before.

That's what my comment implied In this library the security/pairing process is either initiated manually in the application. The specification is being followed, security is optional on a per-attribute basis by setting a flag on it's properties. If you want connections to be secure at all times just call NimBLEDevice::startSecurity when a peer connects.

If really necessary for your application you can just install your own gap handler to handle the security cases that you require with NimBLEDevice::setCustomGapHandler and handle the BLE_GAP_EVENT_PASSKEY_ACTION event yourself for the cases that are not implemented in the C++ API. The stack will generate the events as per the chart as they occur.

[axa88]

So far ive only been using android devices as the initiator, having both keyboard and display using LE Secure Connections. So if configuring the device accurately as having only its keyboard, i was really expecting a way to allow a bond request to proceed without requiring all other devices to authenticate upon connection.
Perhaps I'm looking at it the wrong way... but for some reason expected this flexibility.
Or perhaps I should've expect needing to implement custom programming if this really isn't something worth supporting.
But i'll leave this issue open here for a bit while i try to resolve it in my head