Different SM IO capabilities for different roles not supported

[br101]

As far as I can see there is a global configuration for IO capabilities: ble_hs_cfg.sm_io_cap

I need to support different IO capabilities in different roles, e.g. BLE_HS_IO_KEYBOARD_ONLY in peripheral role and BLE_HS_IO_DISPLAY_ONLY in central role. I can work around it by setting the global configuration prior to initiating a central connection, and then setting it back, but that means if in the mean time a peripheral connects to my device it would not work.

Any possibility to set the IO capabilities per role or connection?

[sjanc]

Hi,

In general IO capabilities describes what devices is able to do and is global by design. So currently it is not possible to override this per connection.

But I'd like to understand why you need this in first place, stacks should be able to pick up best pairing method regardless of role on connection...

[br101]

Yes, I agree that IO capabilities in general are global per device, so in a normal case the design choice of NimBLE is sensible, although not flexible.

In my case I am implementing an automatic passkey algorithm between devices from the same manufacturer, based on some shared secret, and in order for the passkey exchange to happen I have to use matching capabilities e.g. display on one side and keyboard on the other side. May not be the best way, but I need it for compatibility with already existing devices.

I assume that the capabilities are negotiated on a connection basis, so if the capabilities were stored by connection, or asked by callback from the application (like passkey) then we could implement more flexible schemes...

[andrzej-kaczmarek]

Querying for io caps like in the same way as for passkey would be ok, but the problem is that this adds an extra step in pairing process and existing apps will likely fail to handle it properly. I'd rather add a callback to ble_hs_cfg to query for SM settings, it will be used by SM if set by app or global settings will be used otherwise so compatibility with existing apps is retained.

IO caps per connection doesn't seem to have any justification in core spec so this would be a quirk rather than proper API.

[br101]

Yes I understand, I'm also not really pushing for you to include this quirk, but on the other hand I believe NimBLE could benefit from more flexibility, especially when it's relatively easy to implement. Thank you