Hi Scott, >> The biggest problem here is that even if you are trying to be private and doing everything right, the mouse will broadcast your public address every time it tries to reconnect. So thank you Microsoft for forcing us to be trackable. >> > > \o/ > > (I'd had an open bug to investigate why this mouse wasn't > reconnecting, y'all beat me to it) the same applies to the HP mouse btw. I have seen the same problem using the Microsoft and HP mice on OS X about a month ago, but I couldn't be bothered to investigate it. OS X also uses non-resolvable private addresses for scanning. >> Now the biggest problem is that with 3.15 and 3.16-rcX kernels we would need to go back to using our identity address for discovery. This means active scanning and it means we are broadcasting our identity address to everybody when trying to find this mouse. I rather not do that. >> > > I think we would rather just document that this mouse isn't going to > reconnect, since you can at least use the UI to reconnect by hand. > Switching back to active scanning on the identity address would make > our devices trackable, which is very definitely not on our wish list. Besides a minor issue with the GATT channel in bluetoothd on auto-reconnection, I have this nicely working now using the kernel passive background scanning. Which means we can use non-resolvable private addresses for the discovery. However the earliest kernel this goes in will be 3.17 and I still need some minor cleanups here and there to make this smooth. What we most likely are going to do is allow discovery using identity address for 3.15 and 3.16 and then with 3.17 we are switching back to privacy for discovery. Regards Marcel -- 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
