Re: [RFC] New mgmt API for Features Exchange (was: Re: Security level for Primary Services discovery during pairing)

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 [off-list ref] wrote:

Hi,

On Wed, Sep 7, 2011 at 8:28 PM, Ash K [off-list ref] wrote:

quoted

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

quoted

On Tue, Sep 6, 2011 at 12:42 PM, VISHWANATH KM [off-list ref] wrote:

quoted

Hi,

On Tue, Aug 9, 2011 at 3:30 AM, Ash K [off-list ref] wrote:

quoted

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

quoted

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 [off-list ref] wrote:

quoted

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
[off-list ref] wrote:

quoted

Hi,

On Mon, Aug 8, 2011 at 10:59 AM, VISHWANATH KM [off-list ref] wrote:

quoted

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Ash

--
Ash

--
Ash

-- 
Ash