Fix sending alert from the proximity client when the
received RSSI of the remote device equals the threshold
set on the client.
CRs-fixed: 344936
Change-Id: I598d7d66b492cb76754280d657b6e6d55dd0903b
Signed-off-by: Archana Ramachandran <archanar@codeaurora.org>
This feature is required for implementing Low energy
proximity client immediate alert service. The proximtiy
client registers with the kernel for receiving RSSI updates
of the remote device. The kernel starts polling for RSSI
value using READ_RSSI HCI command and When it reaches
a particular threshold set by the proximity client,
updates are sent to the client.
Change-Id: I723dd140ad3bf02978c57b3ab127bb6768f28cca
CRs-fixed: 344936
Signed-off-by: Archana Ramachandran <archanar@codeaurora.org>
Connection security level is modified based on remote device's
extended feature. Deciding SSP capability of remote device
by EIR response is incorrect, because few BT2.1 devices do not
send EIR and few BT2.1 devices which send EIR do not support
SSP. SSP capability of remote device has to be decided based on
remote_extended_features event. This patch makes sure that
MEDIUM_SECURITY is set for non ssp devices' pairing process.
Change-Id: I328a35a30895f2ab6abaaeec51b364ecd633e642
CRs-fixed: 339166
Signed-off-by: Prabhakaran Mc <prabhakaranmc@codeaurora.org>
Expose Bluetooth remote features to the userspace. A2DP profile
setup in the userspace would need this information to
determine if the remote side supports EDR ACL link or not.
Change-Id: Ib6713707baaf30ffe872247313b2185ae2897385
Signed-off-by: Sunny Kapdi <sunnyk@codeaurora.org>
In case both side have no MITM requirements, we need
to use Just Works Association Model. We should not
display PassKey in this case and just YES/NO option
should be displayed
Change-Id: I447aa84a0d021e8834138062a26a9380d3b9b2d9
Signed-off-by: AnubhavGupta <anubhavg@codeaurora.org>
Some rebalancing of refcnts due to issues found during testing:
Refcnt was not being released on security completion, if local side
was paired but the remote side had deleted the pairing info, and then
the re-pair failed to complete successfully.
Additionally, the refcnt was not held-released properly if pairing
was initiated due to the client socket being opened with security
level elevated from the start.
Change-Id: I120fed4dc74035d280781ca949a23d4cbcfa3f3e
CRs-fixed: 335993
Signed-off-by: Brian Gix <bgix@codeaurora.org>
Even after the device is down, some hci commands are getting queued in
some scenarios, since there is no command queue purge mechanism in the
initialization sequence, so the immediate device up initialization
sequence is messed up with unexpected commands.
The current change blocks some of the hci commands to get queued if the
device is down and also purges the queue in the beginning of the next
device initialization sequence.
CRs-fixed: 336160
Change-Id: Ice5a38da47af11babd5b9dd33b9d711ef96e6732
Signed-off-by: Bhasker Neti <bneti@codeaurora.org>
It is possible to redundently request Discovery
operations. This fix cleans up some stored state to
prevent MGMT event overload when discovery finally completes.
Change-Id: I2ffb5c0749df95e40cd39e8c64c87a62a93fb896
CRs-fixed: 329657
Signed-off-by: Brian Gix <bgix@codeaurora.org>
On ACL connection complete with a remote device, the remote
device lmp version should be available with Controller. The
current change is to read this information from controller to
host and update to bluez userspace through management APIs.
Change-Id: Ie152ed98fa0a6cf9ab170a6bb8c6a05b5b9dfcb0
Signed-off-by: Srinivas Krovvidi <skrovvid@codeaurora.org>
This change prevents running timers from being re-initialized
which causes system instablility. Also prevents starting a
discovery operation when already in progress.
CRs-fixed: 328673
Change-Id: Icda36a25fdcb40dab4f95f9cc39ca124b299e308
Signed-off-by: Brian Gix <bgix@codeaurora.org>
When connection initiated from the remote device the class of device
information is required to be updated to userspace through this
event.
Change-Id: I97d715a0b80e12d414ecf03d099955c8b12c82b4
Signed-off-by: Srinivas Krovvidi <skrovvid@codeaurora.org>
To prevent timers from expiring on potentiatially free'd dynamic memory.
Change-Id: I8b9685150bcee72fa7ca71b221bc54b54516021e
Signed-off-by: Brian Gix <bgix@codeaurora.org>
Fixes a deadlock issue due to spinlock being acquired
first in the process context and followed by a second
acquisition in the interrupt context
CRs-fixed: 319052
Change-Id: If17be9fa6f020dd1abd248f8999c2614251fc509
Signed-off-by: Subramanian Srinivasan <subrsrin@codeaurora.org>
mgmt_encrypt_link procedure is added by implementing
MGMT_OP_ENCRYPT_LINK and MGMT_EV_ENCRYPT_CHANGE
Change-Id: Ibed6e24c67bbea83318a67c636e02a93518de29d
Signed-off-by: Prabhakaran Mc <prabhakaranmc@codeaurora.org>
If we initiated a Dedicated pairing, and the remote device
is a NoInputNoOutput capable device, allow auto-acceptance
of pairing.
Change-Id: Ia5cc3e3d458cee98aef0493a423d29e9955638c3
CRs-fixed: 318144
Signed-off-by: Brian Gix <bgix@codeaurora.org>
Include auto-setting connection parameters during Pairing for
low latenecy, and default (high latency) settings for non-Pairing
connections.
Change-Id: Ie8e3f65da52213451dcc01fce38d95ae07d1b13b
Signed-off-by: Brian Gix <bgix@codeaurora.org>
LE-Only devices require that an Address Type (Public or Random) be
included in Connection Requests. This info is available at Pairing
but must be cached so that it is available at reconnection time.
This change includes the Address type with the Pairing data.
Change-Id: I50c78ad31d8be70f5c3f49a0529039e4a26daaac
Signed-off-by: Brian Gix <bgix@codeaurora.org>
If LE devices stop advertising or go out of range, we need
to apply a timeout because the baseband doesn't.
Change-Id: I115672e21fd8aef56ac688b2df4664bb74b725e4
Signed-off-by: Brian Gix <bgix@codeaurora.org>
When sock_put() is called on an L2CAP socket, if the reference count
on a sock goes to 0, l2cap_sock_release() is called. As part of the
release, l2cap_sock_shutdown() locks the socket. This is not allowable
in interrupt context. This change makes calls to sock_put() on the
system workqueue, where it can safely lock.
This addresses "scheduling while atomic" issues in both the Bluetooth
mgmt_ops pairing code and when RFCOMM sessions are deleted in a
security_cfm callback.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
When remote device is connected outside the control of BlueZ, it
needs to be informed of whether the new connection is LE or BR/EDR.
Signed-off-by: Brian Gix <bgix@codeaurora.org>
When LE was added, the refcnt's for the hci_conns used were not balanced
and some of this bleeded over between LE pairing and Legacy pairing.
CRs-fixed: 305391
Signed-off-by: Brian Gix <bgix@codeaurora.org>
Enabled ECB Block encoding for Low Energy pairing
Implemented missing components of MGMTOPS interface
Differentiated as needed between BR/EDR pairing and LE pairing
Signed-off-by: Brian Gix <bgix@codeaurora.org>
Conflicts:
net/bluetooth/mgmt.c
SAP profile requires 16 pin length authentication for BT 1.2/2.0
devices as per specification. These changes were present for hciops
pluging, the current changes are for Management operations plugin.
Signed-off-by: Prabhakaran Mc <prabhakaranmc@codeaurora.org>
In some cases it will be useful having the key size used for
encrypting the link. For example, some profiles may restrict
some operations depending on the key length.
The key size is stored in the key that is passed to userspace
using the pin_length field in the key structure.
For now this field is only valid for LE controllers. 3.0+HS
controllers define the Read Encryption Key Size command, this
field is intended for storing the value returned by that
command.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
As the key format has changed to something that has a dynamic size,
the way that keys are received and sent must be changed.
The structure fields order is changed to make the parsing of the
information received from the Management Interface easier.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Management interface commands for blocking and unblocking devices.
Signed-off-by: Antti Julku <antti.julku@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
As we cannot relay on a userspace mgmt api implementation we should verify
if pin_code_reply in fact contains the secure pin code.
If userspace replied with unsecure pincode when secure was required we will
send pin_code_neg_reply to the controller.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
The get_connections function has no need to use hci_dev_list_lock. The
code was there probably because of a copy-paste mistake.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
__u16 sco_pkt_type is introduced to struct sockaddr_sco. It allows bitwise
selection of SCO/eSCO packet types. Currently those bits are:
0x0001 HV1 may be used.
0x0002 HV2 may be used.
0x0004 HV3 may be used.
0x0008 EV3 may be used.
0x0010 EV4 may be used.
0x0020 EV5 may be used.
0x0040 2-EV3 may be used.
0x0080 3-EV3 may be used.
0x0100 2-EV5 may be used.
0x0200 3-EV5 may be used.
This is similar to the Packet Type parameter in the HCI Setup Synchronous
Connection Command, except that we are not reversing the logic on the EDR bits.
This makes the use of sco_pkt_tpye forward portable for the use case of
white-listing packet types, which we expect will be the primary use case.
If sco_pkt_type is zero, or userspace uses the old struct sockaddr_sco,
then the default behavior is to allow all packet types.
Packet type selection is just a request made to the Bluetooth chipset, and
it is up to the link manager on the chipset to negiotiate and decide on the
actual packet types used. Furthermore, when a SCO/eSCO connection is eventually
made there is no way for the host stack to determine which packet type was used
(however it is possible to get the link type of SCO or eSCO).
sco_pkt_type is ignored for incoming SCO connections. It is possible
to add this in the future as a parameter to the Accept Synchronous Connection
Command, however its a little trickier because the kernel does not
currently preserve sockaddr_sco data between userspace calls to accept().
The most common use for sco_pkt_type will be to white-list only SCO packets,
which can be done with the hci.h constant SCO_ESCO_MASK.
This patch is motivated by broken Bluetooth carkits such as the Motorolo
HF850 (it claims to support eSCO, but will actually reject eSCO connections
after 5 seconds) and the 2007/2008 Infiniti G35/37 (fails to route audio
if a 2-EV5 packet type is negiotiated). With this patch userspace can maintain
a list of compatible packet types to workaround remote devices such as these.
Based on a patch by Marcel Holtmann.
Rebased to 2.6.39.
Change-Id: Ide1c89574fa4f6f1b9218282e1af17051eb86315
Signed-off-by: Nick Pelly <npelly@google.com>
If we can't find a ACL link between the devices, we search
the connection list one second time looking for LE links.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Even for keys that shouldn't be stored some use cases require the
knowledge of a new key having been created so that the conclusion of a
successful pairing can be made. Therefore, always send the mgmt_new_key
event but add a store_hint parameter to it to indicate to user space
whether the key should be stored or not.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
User space shouldn't have any need for the old key type so remove it
from the corresponding Management interface event.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Link keys should only be stored if very specific criteria of the
authentication process are fulfilled. This patch essentially copies the
criteria that user space has so far been using to the kernel side so
that the management interface works properly.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
When accepting a pairing request which fulfills the SSP auto-accept
criteria we need to push the request all the way to the user for
confirmation. This patch adds a new hint to the user_confirm_request
management event so user space can know when to show a numeric
comparison dialog and when to show a simple yes/no confirmation dialog.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Extend the mgmt_pin_code_request interface to require secure
pin code (16 digit) for authentication.
This is a kernel part of the secure pin code requirement notification
to user space agent.
Code styling fix by Johan Hedberg.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
This patch adds a new event to the Management interface to track when
local adapters are discovering remote devices. For now this only tracks
BR/EDR discovery procedures.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
This patch adds start_discovery and stop_discovery commands to the
management interface. Right now their implementation is fairly
simplistic and the parameters are fixed to what user space has
defaulted to so far.
This is the very initial phase for discovery implementation into
the kernel. Next steps include name resolution, LE scanning and
bdaddr type handling.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
