Hi, On Fri, Aug 5, 2011 at 5:21 AM, VISHWANATH KM <a21174@xxxxxxxxxxxx> wrote: > As you mentioned in case if we don't want to trigger SMP we should use > CreateDevice, but how do we know before calling CreateDevice or > CreatePairedDevice if remote supports SMP or not. Does bluez exposes this > info to app. We can use LE_Read_Remote_Used_Features only after LE ACL is > established and that is done as part of either CreateDevice or > CreatePairedDevice (bt_io_connect). Please clarify. thx Now I understand your issue. Currently, BlueZ (and kernel) does not support the "Features Exchange" procedure described on message chart from Vol. 6 Part D Section 6.5 (page 2276). Actually, I could not find any other part of the Core 4.0 spec pointing to this procedure. Do you know where it is used, how it is triggered and whether it is mandatory? I think you have two options: 1) Always use CreateDevice(). Then if you want to issue SMP pairing, you can change the BT_IO_SECLEVEL when connection with bt_io_connect() (I haven't tested this lately, but I remember it used to work). 2) Extend the kernel Management API to allow Features Exchange. See doc/mgmt-api.txt for the existing commands, to have an idea on how it works (I recommend first sending an API proposal here to the list). Also note that *all* currently adopted LE profiles (Find Me, Heart Rate, Health Thermometer, Proximity) require that both sides (initiator and acceptor) support Security Mode 1, Levels 2 or 3 (i.e. SMP pairing is mandatory for them). So, if you are working with a custom profile, you may need to implement the missing bits. I would also like to hear from other BlueZ developers :). Any other ideas? Regards, -- Anderson Lizardo Instituto Nokia de Tecnologia - INdT Manaus - Brazil -- 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
