AccesorySetupKit - device not found when ManufacturerData is present

Question

duoskater OP

Created 2d

Replies 2

Boosts 0

Participants 2

Hello,

I am working on a application that connects to a peripheral using AccessorySetupKit. Peripheral is currently advertising it's custom service UUID. With this setup I am able to discover and connect to the device without issues.

Firmware team wants to introduce a change and add a "manufacturer data" to the advertisment for better recognition. Upon testing with iOS app, it turns out that current code breaks and does not discover the device anymore.

I am unable to configure AccessorySetupKit to be able to discover the device when it has both service uuid and manufacturer data in advertisment. Removing the newly added manufacturer data "fixes" the issue and app is able to discover peripherals again.

Looking at the documentation of ASDiscoveryDescriptor it does not specify that those are mutually excluding fields nor does it provide any insight how the configured fields are evaluated against each other.

Is this a bug in AccessorySetupKit? Is there a way to update the descriptor in a way that application will still be able to discover the peripheral if only service UUID is provided?

Thanks in advance

Boost

Answer 1

Engineer OP

Apple

2d

I would suggest to test, if you have not done so, without adding the manufacturers data blob to your ASDiscoveryDescriptor, and see if the device is discovered by service UUID alone still.

If not, then my suspicion would be, that when adding manufacturer's data, they changed the structure of the advertising packets. Either moved fields back and forth from ADV_IND to SCAN_RSP, or they changed something else to make space for the new data.

I would first bring this up with the firmware team and compare the actual advertising packets between the two cases and make sure something has not been sacrificed.

Or perhaps they switched to extended advertising, which may not be supported if you are using an older iOS device to test.

If the device is discovered without adding the data to ASDiscoveryDescriptor, then this would simply be a mismatch of the advertised data, and the blob you specified. If you have a packet log, then you can compare what is being advertised to your ASDiscoveryDescriptor.

While this could be an issue with Accessory Setup kit as well, we need some more debugging info from your end to assess the issue.

Argun Tekant /  DTS Engineer / Core Technologies

0

Answer 2

duoskater OP

1d

Hey,

Thank you for your reply, I did some testing and used Packet Logger to get more info and here's what I got:

This is how I create ASDiscoveryDescriptor, nothing fancy, declaring the service UUID I am interested in.

let descriptor = ASDiscoveryDescriptor()
            descriptor.bluetoothServiceUUID = CBUUID(string: device.serviceUUID)
            descriptor.supportedOptions = [.bluetoothPairingLE]

Info.plist contains all the required data as well (the same service uuid and Bluetooth for supporred modes).

I'll be using code above to discover the peripheral.

**Case 1 - working scenario: ** In this case peripheral advertises only service uuid in it's advertisment data and it's local name is "Periph-1234". Using packet logger I can see two HCI events: ADV_IN followed by SCAN_RSP

Jun 17 17:19:43.268  HCI Event        0x0000  2C:CF:67:02:8A:4B  LE - Advertising Report - 1 Report - Normal - Public - 2C:CF:67:02:8A:4B - ADV_IND  -31 dBm - Channel 37  
	Parameter Length: 33 (0x21)
	Num Reports: 0X01
	Report 0
		Event Type: Connectable Undirected Advertising (ADV_IND)
		
		Address Type: Public
		Peer Address: 2C:CF:67:02:8A:4B
		Data Length: 21
		Flags: 0x6
			LE Limited General Discoverable Mode
			BR/EDR Not Supported
		128 Bit UUIDs: 9727905B-EC88-AB8F-A041-F77A8D48343D
		Data: 02 01 06 11 07 97 27 90 5B EC 88 AB 8F A0 41 F7 7A 8D 48 34 3D 
		RSSI: -31 dBm
Jun 17 17:19:43.268  HCI Event        0x0000  00:00:00:00:00:00  00000000: 3E21 0201 1000 4B8A 0267 CF2C 1502 0106  >!....K..g.,....  
	00000000: 3E21 0201 1000 4B8A 0267 CF2C 1502 0106  >!....K..g.,....
	00000010: 1107 9727 905B EC88 AB8F A041 F77A 8D48  ...'.[.....A.z.H
	00000020: 343D E1                                  4=.
Jun 17 17:19:43.269  HCI Event        0x0000  2C:CF:67:02:8A:4B  LE - Advertising Report - 1 Report - Normal - Public - 2C:CF:67:02:8A:4B - SCAN_RSP  -31 dBm - Periph-1234 - Channel 37  
	Parameter Length: 25 (0x19)
	Num Reports: 0X01
	Report 0
		Event Type: Scan Response (SCAN_RSP)
		
		Address Type: Public
		Peer Address: 2C:CF:67:02:8A:4B
		Data Length: 13
		Local Name: Periph-1234
		Data: 0C 09 50 65 72 69 70 68 2D 31 32 33 34 
		RSSI: -31 dBm
Jun 17 17:19:43.269  HCI Event        0x0000  00:00:00:00:00:00  00000000: 3E19 0201 1400 4B8A 0267 CF2C 0D0C 0950  >.....K..g.,...P  
	00000000: 3E19 0201 1400 4B8A 0267 CF2C 0D0C 0950  >.....K..g.,...P
	00000010: 6572 6970 682D 3132 3334 E1              eriph-1234.

In this case, using descriptor code above, I have no issues discovering the peripheral.

Case 2 - not working In this case, peripheral includes manufacturer data in in's advertisment packet. it's sets its company identifier and arbitrary data (in this case - a short id with value "1234" for simplicity). Again, using packet logger, I see ADV_IND and SCAN_RSP as follow:

Jun 17 17:22:17.289  HCI Event        0x0000  2C:CF:67:02:8A:4B  LE - Advertising Report - 1 Report - Normal - Public - 2C:CF:67:02:8A:4B - ADV_IND  -32 dBm - Manufacturer Specific Data - Channel 37  
	Parameter Length: 41 (0x29)
	Num Reports: 0X01
	Report 0
		Event Type: Connectable Undirected Advertising (ADV_IND)
		
		Address Type: Public
		Peer Address: 2C:CF:67:02:8A:4B
		Data Length: 29
		Flags: 0x6
			LE Limited General Discoverable Mode
			BR/EDR Not Supported
		128 Bit UUIDs: 9727905B-EC88-AB8F-A041-F77A8D48343D
		Data: 02 01 06 11 07 97 27 90 5B EC 88 AB 8F A0 41 F7 7A 8D 48 34 3D 07 FF FF FF 31 32 33 34 
		RSSI: -32 dBm
Jun 17 17:22:17.289  HCI Event        0x0000  00:00:00:00:00:00  00000000: 3E29 0201 0000 4B8A 0267 CF2C 1D02 0106  >)....K..g.,....  
	00000000: 3E29 0201 0000 4B8A 0267 CF2C 1D02 0106  >)....K..g.,....
	00000010: 1107 9727 905B EC88 AB8F A041 F77A 8D48  ...'.[.....A.z.H
	00000020: 343D 07FF FFFF 3132 3334 E0              4=....1234.
Jun 17 17:22:17.289  HCI Event        0x0000  2C:CF:67:02:8A:4B  LE - Advertising Report - 1 Report - Normal - Public - 2C:CF:67:02:8A:4B - SCAN_RSP  -32 dBm - Periph-1234 - Channel 37  
	Parameter Length: 25 (0x19)
	Num Reports: 0X01
	Report 0
		Event Type: Scan Response (SCAN_RSP)
		
		Address Type: Public
		Peer Address: 2C:CF:67:02:8A:4B
		Data Length: 13
		Local Name: Periph-1234
		Data: 0C 09 50 65 72 69 70 68 2D 31 32 33 34 
		RSSI: -32 dBm
Jun 17 17:22:17.289  HCI Event        0x0000  00:00:00:00:00:00  00000000: 3E19 0201 0400 4B8A 0267 CF2C 0D0C 0950  >.....K..g.,...P  
	00000000: 3E19 0201 0400 4B8A 0267 CF2C 0D0C 0950  >.....K..g.,...P
	00000010: 6572 6970 682D 3132 3334 E0              eriph-1234.

SCAN_RSP is the same in both cases.

the only difference I see is in ADV_IND where its few bytes longer

I played around a little bit with configuration of ASDiscoveryDescriptor and found that setting bluetoothCompanyIdentifier allows me to discover the peripheral regardless if its contains manufacturer data in advertisment packet or not as below (Info.plist needs update as well to include NSAccessorySetupBluetoothCompanyIdentifiers):

let descriptor = ASDiscoveryDescriptor()
            descriptor.bluetoothServiceUUID = CBUUID(string: device.serviceUUID)
            descriptor.bluetoothCompanyIdentifier = .init(rawValue: 0xffff)
            descriptor.supportedOptions = [.bluetoothPairingLE]

I'd expect AccessorySetupKit to discover the peripheral regardless of manufacturer's data when configured to look for service uuid. This behavior is not documented anywhere and documentation is misleading as it explicity states that descriptor requires bluetoothServiceUUID OR bluetoothCompanyIdentifier - not both.

Such situation and undocumented behavior can lead to unexpected behavior with firmware updates.

Can you please confirm if what I observe is a unintentional behavior or an expected one?

0