Also, section 2.1 from core spec 4.0 L2CAP says: 2.1 CHANNEL IDENTIFIERS A channel identifier (CID) is the local name representing a logical channel endpoint on the device. The null identifier (0x0000) shall never be used as a destination endpoint. Identifiers from 0x0001 to 0x003F are reserved for specific L2CAP functions. These channels are referred to as Fixed Channels. At a minimum, the L2CAP Signaling channel (Fixed Channel 0x0001) or the L2CAP LE Signaling channel (Fixed Channel 0x0005) shall be supported. If Fixed Channel 0x0005 is supported, then Fixed Channels 0x0004 and 0x0006 shall be supported (see Table 2.1). Which mean SMP L2CAP (0x0006) channel is mandatory if a device is using LE connection. In least case a implementation would have to implement SMP module which returns error (pairing not supported or command not supported). This procedure could be used to identify if SMP is supported. As I said in earlier mail, SMP procedure might not be invoked until a service requests for it. This might make error handling easier, since once would have just return GATT procedure failure since stating remote device does not support pairing or pairing command. On Mon, Aug 8, 2011 at 12:05 PM, Ash K <ashoksarf@xxxxxxxxx> wrote: > Hi All, > > LE is designed for low energy devices and as far as I can understand > Encryption/security related features are should not be used until the > service requests for it (even if it is supported), this might drain > low energy devices unnecessarily (since some service may not need > security). For example: Device Information service access. > > The correct procedure would be to start security related procedure > once any GATT service request for it. You can see the procedure in > "BLUETOOTH SPECIFICATION Version 4.0 [Vol 3] page 365 of 656" > (Bluetooth 4.0 core spec absolute page number 1725). Attached the flow > chart image from spec. > > As soon as you see a request for security mode, you can assume that > remote device supports SMP and encryption bit can also be verified > from remote feature. > > Let me know thoughts. > > Thanks, > Ashok > > On Mon, Aug 8, 2011 at 10:32 AM, Anderson Lizardo > <anderson.lizardo@xxxxxxxxxxxxx> wrote: >> Hi, >> >> On Mon, Aug 8, 2011 at 10:59 AM, VISHWANATH KM <a21174@xxxxxxxxxxxx> wrote: >>>> 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). >>> >>> Option 2 sounds better, where we use CreatePairedDevice and after the LE ACL >>> is established we can do LE Read Remote features, (similar to what we do for >>> BR i.e we do HCI Read Remote features in conn complete ) and if Encryption >>> feature bit is set then we trigger SMP else we don't, pls let me know if any >>> comments, if this sounds ok then i will mail the changes to this maillist >>> for further review >> >> Let's hear others opinions. Johan, Marcel, Gustavo? >> >> 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 >> > > > > -- > Ash > -- Ash -- 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
