On Tue, Mar 15, 2011 at 10:41:55AM -0400, ext Anderson Lizardo wrote: > Hi Ville, > > On Tue, Mar 15, 2011 at 3:57 AM, Ville Tervo <ville.tervo@xxxxxxxxx> wrote: > > Hi, > > > > On Fri, Mar 11, 2011 at 10:32:51AM -0300, ext Andre Guedes wrote: > >> During a LE connection establishment, the host should be able to infer the > >> bdaddr type from a given bdaddr. > >> > >> To achieve that, during the LE scanning, the host stores the bdaddr and the > >> bdaddr type gathered from advertising reports. The host keeps a list of > >> advertising entry (bdaddr and bdaddr_type) for later lookup. This list will > >> be called Advertising Cache. > >> > >> Since the penality to connect to an unreachable device is relatively high, > >> we must keep only fresh advertising entries on the advertising cache. So, > >> before each LE scanning the advertising cache is cleared. Also, after the LE > >> scanning, a timer is set to clear the cache. > > > > I tested these pathes with a device which had random address. Connection works > > which is good. > > > > How ever I'm not yet sure if mandatory scanning before every connect is > > acceptable. > > IIRC the connection procedure defined on the spec requires this scan. > See for instance the general connection establishment procedure at > page 1715 But it makes "Direct Connection Establishment" impossible. Is it needed to pass PTS for example? > > > > > I have been playing with idea to derive address type from msb bits of the > > address. Any ideaÑ what would lose in that way? > > How can you differ public address type from a random one in this case? > I think the MSB bit checking is only for detecting the type of random > address (static, non-resolvable private, resolvable private) That's true. Address type needs to be known. -- Ville -- 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
