nRF8001 D shows whitelisting behaviour paired with public address peer

[hodrussi]

I’m trying to create a nRF8001 device without the need for any keys, because the device will be inaccessible in mounted condition. Additionally the connection must be secured and unauthenticated (just Works).

In case a new peer device is requesting bonding procedure with my already paired nRF8001-Device, the pairing information is going to be deleted. On the second connection attempt pairing information is deleted and a secured connection can be established.

This works fine with modern Android devices with random resolvable private addresses. However this does not work with my old HTC One (Android 5.0.2) with a public address chip. In case the nRF8001-Device has been bonded with a public address peer, SCAN_REQ and CONNECT_REQ packages are ignored.

Here is a commented sniffer record: public_address_anomaly.pcapng

I read about nRF8001 whitelist setting on link text but the setting is disabled.

Did I miss anything? Is there a second parameter in setup data that must be altered? Is there a documentation of the volatile dynamic data structure? Can the dynamic data be changed to prevent this behaviour?

[David Edwin]

Have you changed the setup date as suggested in the linked case ? By default the Whitelist will be enabled when the devices is bonded to a public address, so it needs to be explicitly disabled. This is also present in the dynamic data, but I think that the dynamic data will follow the setup data.

I have attached the dynamic data format as a reference. Dynamic data interface over ACI.txt

[hodrussi]

I realised that my nRFgo Studio settings create a ublue_setup.gen.out.txt with already disabled whitelist setting. Howerver i managed to alter the setup data as suggested in the link case.

Because the whitelist setting had been turned off previously, altering setup data enabled the filter and my devices with non public address showed whitelist behaviour too.

Additionaly i realised that "Device security" setting in nRFgo affects the whitelisting setting of the setup data. As shown in the image below.

thanks for the dynamic data structure!