Hi Marcel, On Thu, Oct 11, 2012, Marcel Holtmann wrote: > > > > + Features=0000000000000000 > > > > + AddressType=<BR/EDR|LE> > > > > + LEAddressType=<public|random> > > > > > > That is not needed. It is encoded in the address itself. > > > > Not quite true. You cannot distinguish between public and random. But > > once you do know that it's random you *can* figure out what kind of > > random it is from the two most significant bits of the address. > > > > What we discussed on #bluez was that this could simply be a reference to > > what address is indicated by the directory (or filename, if that's what > > we go with) for the device storage, e.g. AddressType=<static|public> and > > for private resolvable addresses (for which we'd have the public address > > in storage) we'd need to check if we have any IRK's to know if we need > > to look for a private address to connect to them. Additionally we could > > have a SupportedTechnologies list like "BR/EDR,LE", "LE", etc (feel free > > to suggest a better name if you want). > > Since we will not store private random addresses, and we turn static > random addresses into a cache. So why do we still need this? We will need to store exactly the same information for static random addresses as for public ones, and not just the "core" data but also profile-specific data. So why would you want to do it in two different ways? Sounds like that just complicates the implementation for no particular gain. 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
