On Thu, Jun 02, 2016 at 02:25:33PM +0200, Stephane D'Alu wrote:
> Adding the "| BLE_GATT_CHR_F_NOTIFY" result in an error when setting
> advertisement, which seems to be: pinkey missing.
>
> 105:[ts=102480ssb, mod=64 level=3] error enabling advertisement; rc=6
> 111:[ts=108336ssb, mod=4 level=0] Command Complete: cmd_pkts=1 ogf=0x0
> ocf=0x0 status=5
>
> I'm using bleprph (0.9-dev) as template, which is already using
> BLE_GATT_CHR_F_NOTIFY for it's Alert service, and I haven't seen such
> pinkey requirement. Any idea on what is wrong?
Hi Stephane,
Unfortunately, it appears you are the victim of a few red herrings :).
I will attempt to explain what is going on below. First, the solution
is to increase the max_client_configs setting by at least two, e.g.,
cfg.max_client_configs = 8;
I believe this change will make the problem go away.
As for the cause of the errors:
> 105:[ts=102480ssb, mod=64 level=3] error enabling advertisement; rc=6
The nimble host uses its own set of error codes, separate from the HCI
error codes. Your confusion is understandable, as we haven't documented
the host error codes anywhere! This is something we'll need to get on
right away. The host error codes are defined in
net/nimble/host/include/host/ble_hs.h. An error code of 6 indicates
memory exhaustion. In this case, the host did not pre-allocate enough
client characteistic configuration descriptors (CCCDs) for a single
connection, so it prevented the application from performing a
connectable advertisement.
You need to increase max_client_configs by 2 (rather than 1) because the
host maintains a cache of CCCDs that aren't tied to any connection. The
formula is:
subscribable-charactericteristics * (max-connections + 1)
Where "subscribable-characteristics" is the number of characteristics
supporting notifications or indications.
The other error:
> 111:[ts=108336ssb, mod=4 level=0] Command Complete: cmd_pkts=1 ogf=0x0
> ocf=0x0 status=5
This is caused by a bug in the hci debug output code. The event being
logged here is the no-op that the controller sends on startup. The
no-op is the only event which does not have a status field. The debug
code assumes all events have statuses, and it prints a bogus value here.
This should be an easy fix, and I'll look at it shortly.
Finally, your email sparked a few thoughts. These are just some musings
that need some more thought, but it will help me to write them down, so
I hope you'll humor me and allow me to do so :).
1. We need better diagnostics. It would be great if a message was
printed to the debug log indicating exactly what failed when you
attempted to advertise.
2. It is too difficult to get all the configuration settings correct.
I'm wondering if we should have the application pass its service table
to ble_hs_init(). That way, the correct values for max_services,
max_attrs, and max_client_configs can all be derived from the table.
One complication here is that the application is currently allowed to
register its services in several steps (multiple calls to
ble_gatts_register_svcs(), each time passing a different table). I
suppose the options are to either a) remove support for multistage
registration, or b) maintain the current configuration behavior, and
make the new service table method optional.
Thanks,
Chris
