> 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 I suppose you mean "create_paired_device expects primary service discovery" This behavior does NOT violate specification. However one should be careful about the use-cases which may include a device which doesn't support SMP. If pairing is initiated a appropriate error should be returned to application, stating "remote device does not support pairing/no facility for secured connection" but it may allow application to access unsecured data transfers. i.e a specific error code stating the reason while returning as pairing failed status. When a application/user receive this error code, application could use GATT/profile specific APIs to access any of supported profiles/services. Also note that primary service discovery procedure does NOT demand need any security. In this use case, we are doing pairing procedure and followed by primary service discovery to identify the services supported, this is not exactly same as simple service discovery. On Wed, Sep 7, 2011 at 10:52 AM, VISHWANATH KM <a21174@xxxxxxxxxxxx> wrote: > 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 > -- 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
