Hi On Wed, Sep 7, 2011 at 8:28 PM, Ash K <ashoksarf@xxxxxxxxx> wrote: > 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. > As per current implementation in l2cap_recv_frame, if we recv SMP error/not supported from remote device then it disconnects the l2cap channel, and create_paired_device expects primary service to happen with security level high, so in this case two procedures are dependent on each other. I am not sure if current behavior is ok ? as from spec section ( 5.3.5.1 Pairing Not Supported by Slave page 649) failure conditions it doesn't mention about either continuing or closing of channel, let me know your opinion. Regards Vishwanath > > 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
