Hi Lizardo, On Tue, Nov 08, 2011, Anderson Lizardo wrote: > > The BREDR_LE option is there for the updated start_discovery command. > > You'll be able to specify whether you want BR/EDR-only, LE-only or > > interleaved discovery. I wouldn't add a completely new octet for public > > vs random information though but reuse the existing one instead. To be > > able to reuse our address type definitions for all purposes, how about > > making each value orthogonal to the others, e.g.: > > > > ADDR_BREDR 0x01 > > ADDR_LE_PUBLIC 0x02 > > ADDR_LE_RANDOM 0x04 > > > > For events like connected, found, etc you'd only have one of the bits > > set whereas for the start_discovery you could have any (but at least > > one). > > Johan: how would link_to_mgmt() in your code work in this case? It'd need to get the LE public/random information somehow. E.g. struct hci_conn will probably need to maintain this information. Another question this also raises is do we do the conversion to MGMT_ADDR_* inside or outside of mgmt.c. > I see this will help simplifying how do we identify LE devices on > BlueZ (currently it is done by parsing AD flags, but broken devices > may lack the correct "BR/EDR not supported" flag, and thus we > incorrectly identify then as BR/EDR). Unfortunately, it will still not > allow us to correctly connect to LE devices without relying on the > kernel's advertising cache. Right. The only way to avoid that would be to add this information to the L2CAP socket address (a decision which we intentionally pushed further into the future by initially adopting the kernel-side cache). 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
