Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

MartinBL — Tue, 30 Oct 2018 15:16:18 GMT

Good to know. Thanks for the information!

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

veletron — Tue, 30 Oct 2018 11:18:12 GMT

I have the same issue re refusal of the Android phone to connect to the directed advertisement (though it does work when the directed advertisement times out and switches to fast advertising). Wireshark shows that the central's public MAC is correct in the packet (matches that reported by phone), but central just wont connect via the directed advertising packet. Thankfully, after directed advertising times out (1 minute in my case), fast advertising starts and the central then immediately reconnects to the peripheral. I am using SDKV6.0 soft device 132.

I had hoped to use directed advertising as a kind of single MAC whitelist, only allowing the previous central the chance to reconnect per power-cycle of my peripheral. Turns out that directed advertising simply is not reliable/predictable enough across a range of devices and thus should not be used. My test device's: Galaxy S7 (android 7.1), Google Nexus 5 (Android 6.0.1) and Samsung Note 8 (Android 8.0) -->None of these can reconnect to the peripheral using the directed advertising packets. Tested using nRFConnect and also my own App, my App makes a connection direct to the peripheral MAC - no filter is used (I am aware that directed advertising includes only the peripheral and central MAC's and no name, UUID etc).

Link to my original thread: https://devzone.nordicsemi.com/f/nordic-q-a/39950/directed-advertising---how-to-make-it-work

'Kenneth' on thread above responded re how to detect from the peripheral whether the central supports directed advertising, which could then be used to choose what to do - but this does not work in my case (single MAC whitelist).

Basically, don't waste your time (I have spent 2 days on this) - directed advertising does not work correctly across all devices. Use fast advertising and the whitelist module instead. <Sigh>.

Nigel

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

Torfinn Berset — Thu, 07 Dec 2017 07:42:52 GMT

@Martin, thanks indeed for spending the time to get to get to the bottom of this. Your explanation was very interesting to read as well, thanks for sharing the details with us. Looking forward to an update in future SoftDevices

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

Matej — Wed, 06 Dec 2017 14:02:38 GMT

@Martin Thank you for detailed explanation! Please let me know when there will be update availabe on that...

Thank you!

BR, Matej

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

MartinBL — Wed, 06 Dec 2017 12:52:52 GMT

Hi,

I have finally been able to reproduce the problem. For testing I used:

Samsung Galaxy S8 running Android 7.0
Nexus 7 Tablet running Android 6.0
Nexus 5X running Android 8.1
nRF Connect for Mobile
The ble_app_hids_mouse example:
nRF52, SDK 14.2, S132 v5.0.0
nRF52, SDK 12.3, S132 v3.0.0
User @Matej also sees the issue with nRF51, SDK 12.3, S130 v2.0.1

The steps to reproduce it are:

Start advertising with the ble_app_hids_mouse example.
All Android devices are now able to scan for, and see the hids_mouse peripheral.
Connect to the peripheral with the Nexus 7.
Bond the peripheral and the Nexus 7
Nexus 7 is added to the whitelist in the peripheral
Disconnect Nexus 7 and peripheral
Using the hids_mouse example, the peripheral will now start directed advertising
Shortly after, the peripheral will start normal undirected advertising again
Now the S8 is no longer able to see the peripheral, but the Nexus 7 and 5X still can.
A simple reset of the peripheral is all it takes to fix it.

Background

The problem seems to be caused by an obscure corner case triggered by a combination of two things:

A specification violation in the Softdevice
A specification violation in the Samsung Galaxy S7/S8 software, the chipset they use, or a combination of both.

The following arguments refer to the Bluetooth Core Specification Version 5.0, but also applies to Version 4.x (chapter numbers and phrasing might be different).

The core of the matter is the RxAdd bit field in the Advertising Channel PDU, and how it is being used in directed and undirected advertising.

Refer to Vol 6, Part B, Ch 2.3 ADVERTISING CHANNEL PDU:

The chapter states that:

The ChSel, TxAdd and RxAdd fields of the advertising channel PDU that are contained in the header contain information specific to the PDU type defined for each advertising channel PDU separately. If the ChSel, TxAdd or RxAdd fields are not defined as used in a given PDU then they shall be considered Reserved for Future Use.

Vol 6, Part B, Ch 2.3.1.1 ADV_IND (undirected advertising) writes nothing about the RxAdd field, implying that the bit is Reserved For Future Use (RFU).

Jumping back to the "General Interpretation Rules" in the Bluetooth specification, the chapter Vol 1, Part E, Ch 2.4 RESERVED FOR FUTURE USE (RFU) states that:

Where a field in a packet, PDU, or other data structure is described as "Reserved for future use" (irrespective of whether in upper or lower case), the device creating the structure shall set it to zero unless otherwise specified. Any device receiving or interpreting the structure shall ignore that field; in particular, it shall not reject the structure because of the value of the field

Furthermore, Vol 6, Part B, Ch 2.3.1.2 ADV_DIRECT_IND (directed advertising) states that:

[…] The PDU shall be used in connectable directed advertising events. The TxAdd in the advertising channel PDU header indicates whether the advertiser’s address in the AdvA field is public (TxAdd = 0) or random (TxAdd = 1). The RxAdd in the advertising channel PDU header indicates whether the target’s address in the TargetA field is public (RxAdd = 0) or random (RxAdd = 1).

The “target address” mentioned here is the address of the phone (peer device) that we successfully connected to our peripheral. In our case, the target address is of type ‘Random’ and hence, the RxAdd bit is set to 1.

So to summarize this:

In directed advertising, the RxAdd bit field is used to indicate whether the address of the peer device, which the advertising packet is intended for, is random or public.
In undirected advertising, the bit field is not used. It is actually completely irrelevant since no peer address is included in the advertising packet and hence, it is considered “Reserved for Future Use".

Cause

Since our phones are able to see the device in one instance, but not the other, I figured that there had to be a difference between the advertising packets. I used a sniffer and found that indeed there is. Before the peripheral does directed advertising the RxAdd bit is 0 according to spec. After I connected, disconnected, did direct advertising, and finally started undirected advertising again, the bit was 1. So what happens is that:

The Softdevice initializes with the RxAdd bit set to 0 according to spec.
The Softdevice starts undirected advertising.
After connecting and disconnecting again, the Softdevice starts directed advertising.
Since the previously connected peer had a random address, the RxAdd bit is set to 1 during the directed advertising.
When the Softdevice finally starts undirected advertising again, it forgets to revert the bit back to 0, violating the spec requirement in Vol 1, Part E, Ch 2.4 RESERVED FOR FUTURE USE (RFU).

The bug in the Softdevice seems to be present in all three SoftDevices mentioned in this case, but it probably affects other SoftDevice versions too. It is a simple bug, but every change we make to the SoftDevice, however small or significant, has to go through vigorous testing and the stack might need to be requalified. Hence, this is not something we can fix and publish overnight and I cannot make any promises about how long it will take.

But why does this seemingly only happen with Samsung Galaxy S7 and S8 Phones?

It seems like these phones also violates the spec requirements in Vol 1, Part E, Ch 2.4 RESERVED FOR FUTURE USE (RFU), by not ignoring the RFU field in undirected advertising packets. The phones probably receive the packets, but chose to filter them out due to the unexpected value in the RxAdd field. Other phones, that correctly ignores the field, can discover and connect just fine, even though there is a spec violation in our Softdevice.

The common denominator in the case seems to be Samsung Galaxy S7/S8 phones, and Android 7. However, there is no guarantee that the issue is not present in other phones, chipsets, and/or operating systems. It could be interesting to try other Galaxy models or Galaxy S7 and S8 with other Android versions. I do not know, and I am not in a position to find out, whether this is a Samsung Galaxy software issue, a chipset issue, or a combination of both.

Workaround

So far, we only see two workarounds:

Easy, but unfortunate: Disable and re-enable the Softdevice after directed advertising.
Complicated, and also unfortunate: If re-enabling the Softdevice is impossible, start directed advertising towards a public dummy address every time after doing directed advertising to a random address. This will set the bit back to 0.

EDITS:

Tested Samsung Galaxy S5 with Android 6.0.1 - Works fine.

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

Torfinn Berset — Tue, 05 Dec 2017 15:09:06 GMT

Glad to hear you could reproduce it @Martin; means I'm not going crazy [yet] :)

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

MartinBL — Tue, 05 Dec 2017 14:01:49 GMT

Hi @Matej and @torfinn. I have finally been able to reproduce this and I can see exactly what you are reporting. I have found that there is a minor change in the advertising packets before and after the direct advertising has occurred and it seems like the Galaxy S7 and S8 phones or the Android 7's BLE stack (or a combination of both) filter out the peripheral device based on this difference. I have asked the Softdevice team and our Android developers for their opinion and I'll get back to you when I know more.

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

Matej — Thu, 23 Nov 2017 14:00:33 GMT

We are using nRF51822, S130 2.0.1 and SDK 12.3.0 (it seems that we use same sdk as @Torfinn:)

And here are android versions: samsung-firmware.org/.../ samsung-firmware.org/.../

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

MartinBL — Thu, 23 Nov 2017 13:09:48 GMT

So all in all the two of you have tried both nRF51 and nRF52, different SDK versions, Softdevice versions, phone brands, and phone OSs. So it may seem like the issue is definitely caused by the Galaxy S7 and S8? Are they both running the same Android OS?

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

Torfinn Berset — Thu, 23 Nov 2017 10:27:05 GMT

Indeed, I am doing the same as @Matej. We currently implemented a workaround for this in our app that we try to reconnect to the last connected MAC address instead of re-scanning for the device.

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

Matej — Thu, 23 Nov 2017 10:08:40 GMT

@Martin: We are trying to connect to the peripheral based on address and not on the content of advertising packet. We don’t filter out any device with nRF Connect.

We noticed that undirected advertising is not detected on S7/S8 phones after ANY directed advertising session.

We can confirm the issue which was reported by @Torfinn: Our problem is that the Samsung Galaxy S8 does not discover the nRF52 after the fast directed advertising mode is over and undirected advertisements start. We have tried having 4 different brand phones running in parallel with the nRF Go scanner app open, and only on the Galaxy S8 it cannot discover the nRF. If we restart the nRF and start immediately in fast undirected advertisement, the S8 finds the nRF instantly.

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

MartinBL — Tue, 21 Nov 2017 14:12:06 GMT

This sounds similar to these two cases:

Are either of you trying to connect to the peripheral based upon the content of the advertising packet (like device names or UUIDs)? @Matej: Are you filtering out devices when you scan with nRF Connect based upon the content of the advertising packet?

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

Matej — Tue, 14 Nov 2017 15:06:00 GMT

Hi guys,

We have similar issue as Torfinn, but we are using nrf51822 and s130 with v12.3.0

It seems that direct advertising somehow confuses Samsung S7, S7 edge and S8. Other Android phones (HTC, CAT, Galaxy S4) and iPhones are working properly.

Our main issue is that we usually don’t see any of direct advertise message (on S7, S7 edge and S8). We didn’t noticed any problem with undirect advertising.

We tested with custom app and with nRF Connect.

Any idea?

BR, Matej

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

MartinBL — Thu, 07 Sep 2017 18:26:17 GMT

So the S8 only connects on directed advertising (after going through steps 1 to 6)?

What scanner app are you talking about? Are you able to see what kind of packets the S8 does or does not send? Just like a sniffer trace?

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

Torfinn Berset — Thu, 07 Sep 2017 12:03:01 GMT

Correction on 1), I always mix up the terms...

The S8 ignores the indirected advertisements from the nRF after having seen the nRF perform a directed advertisement to a different device. If we do a directed advertisement to the S8, that works just fine.

So steps to reproduce, with A) iPhone and B) Samsung S8:

device A connects to nRF performing indirect advertisement
scan for nRF on device B
disconnect from device A (turn off bluetooth on device A)
start directed advertisement to device A in attempt to reconnect
directed advertisement timeout (BT is off on device A, so cannot connect)
start indirect advertisement on nRF
attempt to connect to nRF from device B, but fails

At step 6, device B should be able to find the nRF, but it doesn't

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

Torfinn Berset — Thu, 07 Sep 2017 11:19:50 GMT

Hi Martin,

The S8 is not attempting to connect, it ignores the directed advertisement entirely (we are using scanner app and our own app to verify this). We don't have the issue with other Android phones or iPhones.
Yes, we are really using SD 2.0.1 with SDK 12.3, after I patched some softdevice headers to make it work. We don't have a way of updating the SoftDevice due to a bug in the bootloader from Rigado, but we still want to use the "latest" SDK. We also tried this with the nRF51 (also SD 2.0.1) , and the issue was the same there.
Unfortunately the nRF sniffer tool does not work on macOS (and I don't have Windows)
I can't give you our hex file, as it contains sensitive company IP (nor does it work on a nRF development board, just on our own PCB) . If I had time, I could try to make a minimal example that reproduces the bug, if I had time :)

RE: Samsung Galaxy S8 cannot find nRF52 after Directed Advertisement

MartinBL — Thu, 07 Sep 2017 09:23:28 GMT

I wasn't able to reproduce this.

Do you know if the S8 is attempting to connect? Or does it ignore the the directed advertising entirely.
Do you really use S132 v2.0.1 with SDK 12.3.0? S132 v3.0.0 should be the one compatible with SDK 12.3.
Are you able to provide some sniffer traces?
Do you mind uploading a .hex file or preferably some project files I can use to reproduce it?