If the two procedure are running independently, primary service discovery is not dependent on pairing and pairing is not dependent on primary service discovery, one would return error for pairing and continue with primary service discovery. Once primary service discovery is done, LE ACL can be disconnected. Same way as SDP and pairing can be done onver BR/EDR. > On Tue, Sep 6, 2011 at 12:42 PM, VISHWANATH KM <a21174@xxxxxxxxxxxx> wrote: >> Hi, >> >> On Tue, Aug 9, 2011 at 3:30 AM, Ash K <ashoksarf@xxxxxxxxx> wrote: >>> >>> 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. >> >> I miss the conclusion, so in above case when remote returns error >> (pairing/cmd not supported) do we disconnect the LE ACL link or >> continue with our usecase, ( here the usecase is doing primary service >> discovery and disconnect as part of CreatePairedDevice API), pls >> clarify >> >>> >>> 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 -- 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
