On Wed, Sep 17, 2014, Johan Hedberg wrote: > On Wed, Sep 17, 2014, Jakub Pawlowski wrote: > > >> My use case include scanning for non-paired, non-connected devices, > > >> checking RSSI value and deciding about connection based on > > >> advertisement content, so that won't work. Am I right ? > > > > > > If you know the bdaddr that you're interested in in advance we should be > > > able to tweak the Add Device command to do what you want (e.g. disable > > > duplicate filtering in the case of Action=0x00 entries). However, if > > > what you need is general scanning for any devices (also previously > > > unknown ones) then Add Device doesn't really fit in (since it takes a > > > known bdaddr). For that we'd either need to consider allowing BDADDR_ANY > > > as an accepted parameter or then we'd need to define a new mgmt command. > > > > > > > Unfortunately my case include previously unknown devices. I decide > > wether I should connect (without pairing) based on advertised service > > and RSSI power only. BDADDR_ANY seems good solution. Or maybe we can > > add some parameter that will force not using controller-side whitelist > > for scan? > > With the BDADDR_ANY solution that'd be the trigger not to use the > controller-side white list. Simply disabling the controller side white > list isn't enough since the kernel would still filter out unknown > addresses and never send Device Found mgmt events. Another question is do you guys want active scanning or passive scanning? Right now Add Device is only used for passive scanning whereas Start Discovery does active scanning. If you need also the scan response data from devices (where some may put their UUIDs) then you wouldn't get that with passive scanning. If you need active scanning for any device it might be worth considering sticking to the Start Discovery command and consider changing the kernel to not use duplicate filtering when user space requests to only scan for LE devices. It'd first need to be confirmed however that this whole duplicate filtering parameter is an issue at all (since it has felt more like speculation so far). Johan -- 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
