Return-Path: MIME-Version: 1.0 In-Reply-To: References: From: =?UTF-8?Q?Fran=C3=A7ois_Beaufort?= Date: Thu, 23 Jun 2016 11:27:25 +0200 Message-ID: Subject: Re: Caching device name in different connectable state To: Luiz Augusto von Dentz Cc: BlueZ development Content-Type: text/plain; charset=UTF-8 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: On Wed, Jun 22, 2016 at 6:35 PM, Luiz Augusto von Dentz wrote: > Hi François, > > On Wed, Jun 22, 2016 at 2:10 PM, François Beaufort > wrote: >> I have a bluetooth beacon device that advertises a name depending on >> its configuration (connectable or not). >> Sadly, in Bluez, the first time it sees it while advertising its name, >> it caches it which is nice for future discovery. >> Except it doesn't because I don't want to see this name while it >> advertises in non-connectable state as it is "not" the same device >> anymore (sort of). >> I guess what I'm asking is if we can make Device name aware of the >> connectable state and only use it if it matches state when it was >> cached. > > Not sure I understand the problem correctly but in case the device > changes for one reason or the other it shall change its identity > address, so the device is at fault here as it doesn't change its > address, what it should have happened is that it uses one random > static for beacon mode and another for connectable mode or even better > use rpa for connectable mode so it can be associate properly. > > That said I guess we could deal a little bit better in regarding of > random static addresses, since they can be used by other devices > caching their name may not be a good idea so we should probably take a > similar approach as to other device settings that are not stored for > random address. > Which part of BlueZ code should I have a look at if I want to contribute back to implement this feature? >> See some btmon trace of what it looks like in both configurations: >> >>> HCI Event: LE Meta Event (0x3e) plen 42 [hci0] 5.600723 >> LE Advertising Report (0x02) >> Num reports: 1 >> Event type: Non connectable undirected - ADV_NONCONN_IND (0x03) >> Address type: Random (0x01) >> Address: D0:65:68:C3:6E:88 (Static) >> Data length: 30 >> Flags: 0x06 >> LE General Discoverable Mode > > Btw, the only reason you are seeing this beacon is because it is > marked as discoverable which iirc is wrong since this flag only apply > for connectable peripherals, without this it won't show on regular > discovery, to make beacons visible Im proposing to include them only > if the application has set a filter so we don't clutter regular device > creation dialogs with beacons that cannot be paired. > I'll see if I can update firmware to NOT use "LE General Discoverable Mode" flag there as you're right, it shouldn't be set according to the Bluetooth Spec for a device that simply broadcasts. >> BR/EDR Not Supported >> 16-bit Service UUIDs (complete): 1 entry >> Google (0xfeaa) >> Service Data (UUID 0xfeaa): 10de0263662e706879736963616c2d77656208 >> RSSI: -80 dBm (0xb0) >> @ Device Found: D0:65:68:C3:6E:88 (2) rssi -80 flags 0x0004 >> 02 01 06 03 03 aa fe 16 16 aa fe 10 de 02 63 66 ..............cf >> >> 2e 70 68 79 73 69 63 61 6c 2d 77 65 62 08 .physical-web. >> >> >> >>> HCI Event: LE Meta Event (0x3e) plen 37 [hci0] 114.202975 >> LE Advertising Report (0x02) >> Num reports: 1 >> Event type: Connectable undirected - ADV_IND (0x00) >> Address type: Random (0x01) >> Address: D0:65:68:C3:6E:88 (Static) >> Data length: 25 >> Flags: 0x06 >> LE General Discoverable Mode >> BR/EDR Not Supported >> 128-bit Service UUIDs (complete): 1 entry >> a3c87500-8ed3-4bdf-8a39-a01bebede295 >> Appearance: Tag (0x0200) >> RSSI: -63 dBm (0xc1) >>> HCI Event: LE Meta Event (0x3e) plen 38 [hci0] 114.205892 >> LE Advertising Report (0x02) >> Num reports: 1 >> Event type: Scan response - SCAN_RSP (0x04) >> Address type: Random (0x01) >> Address: D0:65:68:C3:6E:88 (Static) >> Data length: 26 >> Name (complete): Eddystone Config:beta >> TX power: -18 dBm >> RSSI: -61 dBm (0xc3) >> @ Device Found: D0:65:68:C3:6E:88 (2) rssi -61 flags 0x0000 >> 02 01 06 11 07 95 e2 ed eb 1b a0 39 8a df 4b d3 ...........9..K. >> 8e 00 75 c8 a3 03 19 00 02 16 09 45 64 64 79 73 ..u........Eddys >> 74 6f 6e 65 20 43 6f 6e 66 69 67 3a 62 65 74 61 tone Config:beta >> 02 0a ee ... >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > Luiz Augusto von Dentz