Hi Tony, On Tue, May 12, 2015 at 6:16 PM, Tony DiCola <tony@xxxxxxxxxxxxxx> wrote: > Hi all, I'm playing with the latest bluez 5.30 and bluetooth low > energy devices and am noticing that the manufacturer data field from a > device's advertisement data appears to be cached somewhere internally. > I wanted to check if this was expected and see if there was any way to > disable that caching or work around getting back stale manufacturer > data. > > For some context I'm using bluez 5.30's dbus API and applied these > patches to make the gatt support non-experimental (so I can run > bluetoothd without the --experimental flag): > https://chromium.googlesource.com/chromiumos/third_party/bluez/+/2b3a91a12c86a5708329edf58d0cea237f319f6f%5E%21/#F0 > https://chromium.googlesource.com/chromiumos/third_party/bluez/+/5755965a9944f158dd8aba63655f2b0a414a1f49%5E%21/#F0 > However I've also tried it with the stock 5.30 code and the > --experimental flag and see the same results. > > For my device I'm using a Nordic nRF51822-based board that I have > control over the firmware and am using it to send custom advertisement > data for my device. In my advertisement data I'm sending manufacturer > data that looks like this: 0x07FFFFFF00000001. This breaks down as > the length of the advertisement section (0x07 bytes), the manufacturer > data advertisement type (0xFF), the testing manufacturer ID (0xFFFF), > and then 4 bytes with a value of 1 (0x00000001). > > I see when I enable scanning on an adapter that a device object is > created for my device in bluez's dbus hiearchy. It has a > ManufacturerData field that looks just like what my advertisement > sends, for example here's the output of the device's dbus tree (using > python): > > [ /org/bluez/hci0/dev_C5_25_55_09_6A_B1 ] > org.bluez.Device1 > Name = UART > Paired = 0 > Adapter = /org/bluez/hci0 > LegacyPairing = 0 > Alias = UART > ManufacturerData = dbus.Dictionary({dbus.UInt16(65535): > dbus.Array([dbus.Byte(0), dbus.Byte(0), dbus.Byte(0), dbus.Byte(1)], > signature=dbus.Signature('y'), variant_level=1)}, > signature=dbus.Signature('qv'), variant_level=1) > Connected = 0 > UUIDs = dbus.Array([], signature=dbus.Signature('s'), variant_level=1) > Address = C5:25:55:09:6A:B1 > Trusted = 0 > Blocked = 0 > > Everything looks great and the manufacturer data is parsed out as I > expect. However the problem is when I have the nRF51822 change the > advertised manufacturer data. For example if I change to > 0x07FFFFFF00000002 (so the last 4 bytes change to 0x00000002) I'm not > seeing the updated value in bluez's dbus hierarchy. When I query the > device object's ManufacturerData property I still see the old value > that ends in 1. Even if I sit in a loop querying the value every > second for over a minute I still don't see the updated value (for > reference the nRF51822 is advertising this updated value every > second). > > I do notice that if I remove the device from bluez's dbus hiearchy (by > getting its parent adapter and calling RemoveDevice on it) then I do > see the device added back with the current/updated ManufacturerData > property. This makes me think there's something up with the > manufacturer data field getting cached or never being updated. > > I wanted to check is this expected behavior, that the manufacturer > data property won't be updated when it changes? If so is there any > clean way to disable this caching or get access to the most recently > seen/up to date manufacturer data field? > > Let me know if anything isn't clear or if perhaps I'm doing something > completely wrong. Thanks! > > -Tony > -- > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html BlueZ doesn't update the Advertising Data unless there is an active discovery client or the device is already paired. Is the device paired, or are you calling the StartDiscovery method on the device? Note that the link layer does not need to send duplicate reports (the same device address) to the host even if the advertising data changes. This is acceptable behavior per the spec, as outlined in Vol 6, Part B, Section 4.4.3 "Scanning State": "The advertising data may change; advertising data or scan response data is not considered significant when determining duplicate advertising reports." -- M Janssen -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
