Meizu M2 IRK not resolved

[Valer_I]

Hello, I experienced connection issues with Meizu M2 phone. My device is nRF51822 + S110 softdevice. It works perfecty with iPhone and Android 6+ that uses IRK and random private resolvable address but not with Meizu. To reproduce:

• Connect and create bond with Meizu.

• Disconnect and run whitelist advertising with IRK that corresponds to Meizu.

By sniffing I see that Meizu sends scan requests, but nRF51822 does not answers with scan responce. After adding some debug i noticed that IRK is the next:

0000000000006036D752055F5F3A0000

Yes it is not a good idea to have so many zeros in the key, but could it cause the problem by braking AAR process?

UPDATE:

Sniffer log: Meizu2_cap_1.pcapng Description:

Lines: 48-1626 - Connection, bonding, service discovery and common operation. Than device disconnected from central and started whitelist advertising with IRK 0000000000006036D752055F5F3A0000. Sniffer, device and Meizu phone placed nearby. By sniffer meta rssi level near -45dbm we can see scar request packets from Meizu but no scan responce from device (RPR addr 31:b7:0b:00:c7:57).

At line 1880 I disabled bluetooth module at Meizu and scan req packets stopped.

At line 2010 I enabled bluetooth on Meizu and it tried to connect but device skipped this request as filter policy was configured as BLE_GAP_ADV_FP_FILTER_BOTH in adv parameters.

[Hung Bui]

The IRK is generated by the phone. So it is possible that the IRK can contains lots of zero depends on the algorithm used to generate it.

I would suggest you to capture a sniffer trace, then we can clearly see which IRK is exchanged and what happens when they re-connect.

[Valer_I]

Original question updated.

[Hung Bui]

Hi Valer,

I'm suspecting that the IRK may not match the address, causing the nRF5 to ignore the scan request and connect request. If you turn off whitelist mode (or only whitelist Connect request, not scan request) do you see the difference ?

We have some code here that you can use to test if the IRK and the address is matched or not. Could you please try ?

[Valer_I]

I changed the filter policy and now receive BLE_GAP_EVT_SCAN_REQ_REPORT. The Meizu's scan address type is Private Non-Resolvable... So IRK provided during the bonding procedure is useless.

[Hung Bui]

Good to know Valer. Sorry that I didn't spot that at the beginning. We have seen devices that did the same thing. My suggestion is to ignore the IRK exchange when the public address is used when doing Connect Request.