Issue with BLE Privacy

I'm experiencing an issue when I enable BLE privacy. I'm testing the wireless UART example on the FRDM-KW41Z devkit. With privacy enabled, I'm only able to pair one phone with the device and after I pair, no further phone is able to connect. Example: connect android phone and pair, now iPod can't connect. Same happens if I pair the iPod first - now the android can't connect. For some reason, bluetooth under Linux can connect regardless of this (using gatttool command line). Any thoughts? It doesn't look like the wireless UART enables any kind of white list. Using the NXP sniffer, I see the CONNECT_REQ but silence from the intended device. The advertising PDU type is ADV_IND.

Changes made to code to facilitate this testing:

- disable Gap_SendSlaveSecurityRequest as that was causing gatttool issues likely because it wasn't programmed to deal with pairing

- fix BleConnManager_GapDualRoleConfig as per another one of my threads so it advertises using the Random address

- disable BleServDisc_FindService as that also was causing gatttool problems

More testing under with the BlueZ stack on linux - it appears to connect just fine when it uses a public address but when I set it to use a random address (which the android and ipod were doing), it fails just the same. So it appears to be a bug in the controller privacy where random addresses that aren't in the resolving list fail?

I was using nRF Connect on both Android and iOS, also used LightBlue Explorer on iOS. WUART was peripheral. There shouldn't be any other security settings beyond that which was set in the WUART demo as provided (other than changes as listed).

It seems that when gAppUsePrivacy_d is enabled, when you perform a new connection with a new device, in this case iPhone/Android using nrf Connect or any other similar app, the process goes well, and adds the device to the white list.

When you try to connect using a new device, it seems the connection is being rejected because it is searching for the new device on the white list instead of adding it as a new device.

We will keep reviewing this since we are not sure if is a bug or is just how the application is designed.

It seems that we have isolated the issue and found the root cause. The main root cause for this issue, is a spec ambiguity of what happens after scanning with privacy for a second device after one device already bonded. According to SW team, they will be able to provide a fix/patch by end of June.