petzval / btferret

Python and C Bluetooth Library
MIT License
111 stars 21 forks source link

Manufacturer code #27

Closed gregoiregentil closed 6 months ago

gregoiregentil commented 1 year ago

In the code, I see:

unsigned char leadvert[40] = { 36,0,0,0,0x01,0x08,0x20,0x20,0x0F,0x08,0xFF,0x34,0x12,
0x00,0x00,0xC0,0xDE,0x99,0x05,0x08,0x61,0x62,0x63,0x64,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 };

btmon says:

< HCI Command: LE Set Advertising Data (0x08|0x0008) plen 32    [hci0] 6.798348
        Length: 17
        Company: not assigned (50087)
          Data: 0000c0de99

What is the relation between 0xC0,0xDE,0x99 and 50087? Android sees 50087.

petzval commented 1 year ago

Btferret uses the manufacturer data for its mesh network. So by the time advertising starts, the data is mesh protocol info which would be meaningless to Android.

gregoiregentil commented 1 year ago

I'm still interested to leverage the manufacturer code in Android. As I don't use the Mesh feature, can I overwrite the manufacturer code in btlib.c?

To give some context, multiple times, I see this situation which Android doesn't see the name of the device the first time but it sees the manufacturer code. After a restart of the Android application and nothing has changed on the device, it starts to show the name. I don't know if the advertisement packet is somehow cut in the air. I don't think it's a btferret bug but leveraging the manufacturer code would help me to alleviate this situation.

See the Android log that describes my situation:

04-24 16:16:55.310  3171  3171 I Capacitor/Console: File: http://localhost/main.js - Line 365 - Msg: onBluetoothDeviceFound {"device":{"deviceId":"70:2C:1F:6C:81:4A"},"rssi":-61,"txPower":127,"manufacturerData":{"50087":{}},"serviceData":{},"uuids":[],"rawAdvertisement":{}}
//////Restart app, nothing has changed on the device running btferret
04-24 16:17:19.405  3171  3171 I Capacitor/Console: File: http://localhost/main.js - Line 365 - Msg: onBluetoothDeviceFound {"device":{"deviceId":"70:2C:1F:6C:81:4A","name":"MyNameBleDevice"},"localName":"MyNameBleDevice","rssi":-64,"txPower":127,"manufacturerData":{"50087":{}},"serviceData":{},"uuids":[],"rawAdvertisement":{}}
petzval commented 1 year ago
unsigned char leadvert[40] = { 36,0,0,0,0x01,0x08,0x20,0x20,0x0F,0x08,0xFF,0x34,0x12,
0x00,0x00,0xC0,0xDE,0x99,0x05,0x08,0x61,0x62,0x63,0x64,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 };

The manufacturer code is 0x1234 at [11]. The name is "abcd" at [20], so the name length is 4. Two length bytes include the name length [18]=5=length+1 [8]=15=length+11. Make a new version, say myleadvert and replace all sendhci(leadvert,0) with sendhci(myleadvert,0). If no mesh data has been sent btferret always advertises the name, but Android might have seen the name advertised by bluez before btferret started and stored it in its cache, and will ignore the new name. All Android scan filters need to be turned off - especially ignore repeats - so that every advert goes through to scanCallback/onScanResult and then read the name from the raw data on every advert in case it has changed. Do not get the name that Android supplies - it will come from the cache.

petzval commented 1 year ago

Here's the same issue with the code I posted to read the name in onScanResult

https://stackoverflow.com/questions/72319073/how-to-refresh-bluetooth-device-name-scan-cache/72362989?noredirect=1#72319073