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

[[email protected]]

Yes, indeed I have both - the black-box central as well as the black-box peripheral (the one I'm going to substitute now).

After CONNECT_IND (central) and exploring the GATT profile, the peripheral has to send a special value (probably in a short opened time window). After receiving this cookie the central sends another special value, so the peripheral knows the central fits. Only this way both sides keep the connection, otherwise it will be dropped.

Unfortunately my central "forgets" to enable notification - the channel, where the cookie from the peripheral is expected.

The image taken from wireshark shows, how to connect successfully - both black-boxes (central and pheripheral)

The "aa5501aa" is the cookie sent from peripheral to central. The central answers 2x with "aa5501bb"

[Edvin]

Hello Matthias,

The reason the central "forgets" to send an enable notifications message can be caused by anything. We don't know what code is running on it. For all we know the central application logic could be something like:

Only enable notifications if the BLE address belongs to a specific company (since I can see from your screenshot that the device uses a vendor specific BLE address (many call them MAC address). That is why you can see "company name" followed by 3 bytes in the address field, instead of just 6 bytes in the address field.

Nonetheless, if you have the peripheral blackbox as well, did you try to connect to it using nRF Connect for Desktop -> Bluetooth Low Energy, and look at all the services and characteristics that it has? Do you have all those characteristics in your peripheral application?

BR,

Edvin

[[email protected]]

Hello Edwin,

finally I've managed to fake nearly all of them - advertising packet, scan response, device address, GATT profile 0x180A (DIS) and 0x1000 the customer functions, where the secret cookies should be exchanged.
For GATT inspection I did use the GATT Browser from Renesas (very useful because displayed data do not disappear when device is disconnected - but don't forget to switch to light theme on iOS, otherwise the font vanishes...).
Some entries in 0x180A (DIS) are missing, and I couldn't figure out how to add a user description to each GATT function.
The black-box central tries to connect to my nordic implementation, and after a few attemps it works sometimes. But it seems to me to be a timing problem - the central opens a short timing window after it has discovered the peripheral GATT profile - this small window I have to hit with my cookie.
But when thsi window opens depends on how much traffic is on the air.

So it would be greate to have an event when GATT profiling is in progress or finished - is there a possibility to get a user callback function involved?

Thanks in advance - Matthias

[Edvin]

[email protected] said:

the central opens a short timing window after it has discovered the peripheral GATT profile - this small window I have to hit with my cookie.

What exactly do you mean by this?

I am not aware of any events generated on the peripheral when the central has finished it's service discovery, if that is what you mean? What do you need to do at this point in time? Is it something that you see from the sniffer trace of the two original devices?

BR,
Edvin