How to establish notifications without a subscription?

[[email protected]]

My task looks like Case ID: 115570, but now running nRF SDK 2.1.3 on nRF52840-DK.

My GATT server (Peripheral) has to send a special msg (see log) right after CONNECT_IND using a notification service to the Central. The Central itself cannot be changed (old BT 4.2 device, no source code...).
But I cannot send notifications without a subscription. 

[00:00:17.341,705] <inf> PP: Connected to con 0x20001388: 72:04:D2:F5:8F:47 (random)
[00:00:17.939,605] <inf> PP: Sende ACK
[00:00:17.939,636] <dbg> remote: send_ack: conn 0x20001388 msg bc5301dd
[00:00:17.939,666] <wrn> bt_gatt: Device is not subscribed to characteristic

How can I enable sending notification messages without having a subscription from Central using SDK 2.1.3 ?

 

[Edvin]

Hello,

It is not possible for the peripheral to enable notifications without the central actually requesting it, as it is against the BLE specification. 

I am not sure why you would want to do so, as the central wouldn't know what to do with, or how to handle, the incoming data either way. So even if it was possible to trick the BLE stack into believing that the central already enabled notifications, I doubt it would work the way you expect it to work.

If the case is that you have a central that you don't have the source code to, it probably enables notifications if there is a certain service/characteristic present on the peripheral. You need to figure out what that peripheral service characteristic is, and then set up that very service/characteristic. 

The easiest way to figure that out is if you have the peripheral that the central works with, and try to connect with that peripheral using nRF Connect for Desktop -> Bluetooth Low Energy, and see what services and characteristics that are present on that device.

Best regards,

Edvin

[[email protected]]

Hello Edvin,

so my guess was right - no one wants to receive messages if not signed in for it...
But unfortunately this strange behavior is used to decide on connect, if both sides fit together.

Since bt_gatt_notify() did not work at this place, I’ve tried bt_gatt_write() and bt_gatt_write_without_response() with some success. I can send my magic cookie, but with Opcode "Write Request" (0x12) and "Write Command" (0x52) when Opcode "Handle Value Notification" (0x1b) is expected.

As you can see - this project made me become very familiar with your BLE Sniffer on Wireshark - this tool saved my hole work, thanks a lot to Nordic! Next I will scrutinize all the possibilities of my black-box central device.

Best regards - Matthias

[Edvin]

bt_gatt_write() or bt_gatt_write_without_response() only works if there is a service/characteristic present on the central that you can write to. If it doesn't have any characteristics (most centrals don't have services/characteristics), then there is nowhere to address these writes.

Best regards,

Edvin

[[email protected]]

Would be gatt_req_send() an opportunity?

[Edvin]

gatt_req_send() is just a layer below bt_gatt_write() and all those. Just a common way to prepare and send the actual packet on over the air. 

I am sorry, but the issue is that in the fundamentals of Bluetooth LE, there is no way to send custom payload data without having a characteristic inside a service to attach it to. 

Although BLE is a common language that many devices use, not all BLE devices work together, especially if they don't know what to expect from the connected device. 

Let us say that you somehow managed to connect a BLE mouse to a BLE keyboard. The keyboard wouldn't have any place to send its's keyboard data, because the mouse isn't interested in it. And even if there was a way to trick the BLE stack into thinking the mouse enabled notifications on the keyboard's key service, so that the keyboard started sending notifications, the mouse wouldn't know what to do with that information.

A computer, however, would recognize both the mouse and the keyboard, and it would enable notifications, and it would know what to do with the incoming data.

I hope that made some sense, and wasn't only confusing.

BR,
Edvin

[[email protected]]

Hello Edvin,

it's not at all confusing, the matter is clear. Thanks for your explanations.
Nevertheless I have to solve the problem, i.e. overcome the problems of a buggy BLE firmware of a black-box device I cannot change.

After a closer look it seems to be a time critical problem as well. Now I'm looking for a solution to get an event on my Pheripheral when GATT profile enumeration is initiated or is done.
Any suggestions?

Thanks - Matthias

[Edvin]

Hello Matthias,

I understand. Unfortunately, a black box central is more difficult than a black box peripheral.

Do you have access to a black box peripheral that goes with this black box central?

It sounds like you are able to connect to your central. This means that the central decides to connect to your peripheral (it is always the central that initiates the connection). How did you know what you needed in order for the central to connect?

I am just trying to catch up with what you already know, and perhaps we can figure out a way to understand what your central is looking for.

BR,

Edvin