BLE peripheral giving null for peripheral.name at didDiscoverPeripheral in Mojave

When the peripheral name is advertised on the SCAN_RSP packet, the first didDiscover() call may not have the name data, but a subsequent didDiscover() call for the same peripheal may have the name field populated.

If that's not happening, you may want to get an airtrace to see if the ADV_IND -> SCAN_REQ -> SCAN_RSP sequence is happening.

If we start scan giving null instead of service UUID, its hitting didDiscover multiple times giving the subsequent call giving peripheral name. but when try search with service UUID the peripherals name is always empty.

So for now we have added some logic to tackle the problem(we have scanned without UUID, didDiscover call multiple times for same device with giving needed info in seperate calls) and came up with a workaround. Wondering why it is not working when scan with service UUID asif in old OSX versions.

I have the same problem.

In my opinion, something has changed in 10.14's CoreBluetooth that breaks previously working apps.

I'm logging from my centralManager:didDiscoverPeripheral:advertisemenData:RSSI: delegate callback.

My app initially called CentralManager's scanForPeripheralWithServices:options: passing an array with the required service 00001523-1212-EFDE-1523-785FEABCD123.

In my Mac Mini with OSX 10.13, my callback logged as follows:

2019-01-23 19:28:12.430544+0100 WAD®LS Pairing Tool[29646:1572630] LSManager: Did discover peripheral.

peripheral: <CBPeripheral: 0x6000001066f0, identifier = 48E1D646-F06E-48FF-BAD0-B0ED4BC24BEF, name = WAD_LS_261CE2EA, state = disconnected>

rssi: -61,

advertisementData: {

kCBAdvDataIsConnectable = 0;

kCBAdvDataServiceUUIDs = (

Battery,

"00001523-1212-EFDE-1523-785FEABCD123"

);

}

In my Macbook Air with OSX 10.14, my callback logs as follows:

019-01-23 19:30:48.875927+0100 WAD®LS Pairing Tool[2086:84234] LSManager: Did discover peripheral.

peripheral: <CBPeripheral: 0x600003509340, identifier = B4E115CB-C722-473D-8C76-E2FA782E4D97, name = (nil), state = disconnected>

rssi: -52,

advertisementData: {

kCBAdvDataChannel = 37;

kCBAdvDataIsConnectable = 0;

kCBAdvDataServiceUUIDs = (

Battery,

"00001523-1212-EFDE-1523-785FEABCD123"

);

}

Notice how in 10.14 name is nil, it comes from peripheral.name, which is nil in 10.14.

My app keeps a list of devices which it should connect to, and whether to connect or not is decided by name. It only connects to devices which have the required service and its name is in a whitelist.

I already have a workaround for my app to work, but it involves:

- 1) scanning without service filter, so I get device discovery callbacks for any nearby BLE device;

- 2) analysing 2 calls to the callback, the first for annotating name and the second for testing if device has the desired service.

In this post I have omitted calls to the discovery callback for many other devices, but they appear.

In my Mac Mini with OSX 10.13, both calls to the callback have the peripheral.name set to the device name

2019-01-23 18:32:59.037818+0100 WAD®LS Pairing Tool[29167:1546005] LSManager: Did discover peripheral.

peripheral: <CBPeripheral: 0x600000102be0, identifier = 48E1D646-F06E-48FF-BAD0-B0ED4BC24BEF, name = WAD_LS_261CE2EA, state = disconnected>

rssi: -66,

advertisementData: {

kCBAdvDataIsConnectable = 1;

kCBAdvDataLocalName = "WAD_LS_261CE2EA";

}

2019-01-23 18:32:59.046726+0100 WAD®LS Pairing Tool[29167:1546005] LSManager: Did discover peripheral.

peripheral: <CBPeripheral: 0x600000102be0, identifier = 48E1D646-F06E-48FF-BAD0-B0ED4BC24BEF, name = WAD_LS_261CE2EA, state = disconnected>

rssi: -67,

advertisementData: {

kCBAdvDataIsConnectable = 0;

kCBAdvDataServiceUUIDs = (

Battery,

"00001523-1212-EFDE-1523-785FEABCD123"

);

}

In my Macbook Air with OSX 10.14, the first call has the name set, but in the second call the name is nil. Notice how the device identifier is the same for both calls, which lets me know both calls are from the same device and perform my workaround.

2019-01-23 18:19:25.641195+0100 WAD®LS Pairing Tool[1945:41314] LSManager: Did discover peripheral.

peripheral: <CBPeripheral: 0x600003505970, identifier = B4E115CB-C722-473D-8C76-E2FA782E4D97, name = WAD_LS_261CE2EA, state = disconnected>

rssi: -55,

advertisementData: {

kCBAdvDataChannel = 37;

kCBAdvDataIsConnectable = 1;

kCBAdvDataLocalName = "WAD_LS_261CE2EA";

}

2019-01-23 18:19:25.641386+0100 WAD®LS Pairing Tool[1945:41314] LSManager: Did discover peripheral.

peripheral: <CBPeripheral: 0x600003505970, identifier = B4E115CB-C722-473D-8C76-E2FA782E4D97, name = (nil), state = disconnected>

rssi: -55,

advertisementData: {

kCBAdvDataChannel = 37;

kCBAdvDataIsConnectable = 0;

kCBAdvDataServiceUUIDs = (

Battery,

"00001523-1212-EFDE-1523-785FEABCD123"

);

}

It seems that the 10.14 OSX CoreBluetooth implementation "forgets" the device name in the second call to didDiscoverPeripheral.

This behaviour has broken an app which was working seamlessly, and has forced me to deliver a workaround which makes the app code more complex unnecessarily.

I think this behaviour should be fixed and reverted to previous behaviour.

Regards,

David Crespo

I'd say file a radar with Apple but they don't care about Core Bluetooth on macOS. In fact they've recently closed some of my bugs without fixing them saying "much has changed" since I reported it, but it's still broken. I stopped spending my time filing detailed bug reports for them after that. Perhaps their QA team could just do their jobs.