Store the connection latency and supervision timeout default values
with all the other controller defaults. And when needed use them
for new connections.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

Since the auto-connection handling has gained offical management
command support, remove the le_auto_conn debugfs entry.

For debugging purposes replace it a simple device_list debugfs
entry that allows listing of the current internal auto-connection
list used for passive scanning.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

When the slave updates the connection parameters, store also the
connection latency and supervision timeout information in the
internal list of connection parameters for known devices.

Having these values available allowes the auto-connection
procedure to use the correct values from the beginning without
having to request an update on every connection establishment.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

When calling hci_conn_params_clear function, it should update the
background scanning properly and not require a separate call to
update it.

For the case when the function is used during unregister of a
controller, an extra safe guard is but in place.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

When hci_conn_params_clear is called, it is always followed by a
call to hci_pend_le_conns_clear. So instead of making this explicit
just make sure it is always called. This makes this function similar
on how hci_conn_params_add and hci_conn_params_del work.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

The hci_pend_le_conn_* function should be placed before their actual
users. So move them before hci_conn_params_* functions.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

The usage of non-resovlable private addresses for passive scanning is
a bad idea. Passive scanning will not send any SCAN_REQ and thus using
your identity address for passive scanning is not a privacy issue.

It is important to use the identity address during passive scanning
since that is the only way devices using direct advertising will be
reported correctly by the controller. This is overlooked detail in
the Bluetooth specification that current controllers are not able
to report direct advertising events for other than their current
address.

When remote peers are using direct advertising and scanning is done
with non-resolvable private address these devices will not be found.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

Bluetooth controllers that are marked for raw-only usage can only be
used with user channel access. Any other operation should be rejected.

This simplifies the whole raw-only support since it now depends on
the fact that the controller is marked with HCI_QUIRK_RAW_DEVICE and
runtime raw access is restricted to user channel operation.

The kernel internal processing of HCI commands and events is designed
around the case that either the kernel has full control over the device
or that the device is driven from userspace. This now makes a clear
distinction between these two possible operation modes.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

The ssp_debug_mode debugfs option for developers is no longer
needed. Support for using Secure Simple Pairing (SSP) debug
mode is exposed by the management interface now.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

There are two callers of hci_add_link_key(). The first one is the HCI
Link Key Notification event and the second one the mgmt code that
receives a list of link keys from user space. Previously we've had the
hci_add_link_key() function being responsible for also emitting a mgmt
signal but for the latter use case this should not happen. Because of
this a rather awkward new_key paramter has been passed to the function.

This patch moves the mgmt event sending out from the hci_add_link_key()
function, thereby making the code a bit more understandable.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

By returning the added (or updated) key we pave the way for further
refactoring (in subsequent patches) that allows moving the mgmt event
sending out from this function (and thereby removal of the awkward
new_key parameter).
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Create a CoC dynamically instead of one fixed channel for communication
to peer devices.
Signed-off-by: NJukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

All the special settings configured via debugfs are either developer
only options or temporary solutions. To not clutter the standard flags,
move them to their own dbg_flags entry.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

When the rename of STK_SLAVE to simply STK happened we missed this place
in the ltk_type_master function. Now, checking for master is as simple
as checking whether the type is SMP_LTK. The helper function is kept
around for better readability in the (right now three) callers and for
simpler extension with new key types in the future.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Tested-by: NLukasz Rymanowski <lukasz.rymanowski@tieto.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The LTK type has really nothing to do with HCI so it makes more sense to
have these in smp.h than hci.h. This patch moves the defines to smp.h
and removes the HCI_ prefix in the same go.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Since the whole HCI command, event and data packet processing has been
migrated to use workqueues instead of tasklets, it makes sense to use
struct delayed_work instead of struct timer_list for the timeout
handling. This patch converts the hdev->cmd_timer to use workqueue
as well.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

There are no users of the smp_chan struct outside of smp.c so move it
away from smp.h. The addition of the l2cap.h include to hci_core.c,
hci_conn.c and mgmt.c is something that should have been there already
previously to avoid warnings of undeclared struct l2cap_conn, but the
compiler warning was apparently shadowed away by the mention of
l2cap_conn in the struct smp_chan definition.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch adds conn_info_min_age and conn_info_max_age parameters to
debugfs which determine lifetime of connection information. Actual
lifetime will be random value between min and max age.

Default values for min and max age are 1000ms and 3000ms respectively.
Signed-off-by: NAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

With this patch it is possible to control discovery interleaved
timeout value from debugfs.

It is for fine tuning of this timeout.
Signed-off-by: NLukasz Rymanowski <lukasz.rymanowski@tieto.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The ssp parameter is supposed to be a mandatory one and there are no
callers that would pass NULL to this function. Removing this unnecessary
NULL check also makes (false positive) static analyzer warnings go away.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

All callers of hci_inquiry_cache_update() pass a non-NULL ssp pointer to
it and even the function itself assumes in another place that the
pointer is non-NULL. Therefore, remove the redundant check.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch does a small code simplification replacing the tipical
kmalloc-copy_from_user sequence by memdup_user() helper.

Cc: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The use of __constant_<foo> has been unnecessary for quite awhile now.

Make these uses consistent with the rest of the kernel.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

To avoid flooding the host with useless advertising reports during
background scan, we enable the duplicates filter from controller.

However, enabling duplicates filter requires a small change in
background scan routine in order to fix the following scenario:
  1) Background scan is running.
  2) A device disconnects and starts advertising.
  3) Before host gets the disconnect event, the advertising is reported
     to host. Since there is no pending LE connection at that time,
     nothing happens.
  4) Host gets the disconnection event and adds a pending connection.
  5) No advertising is reported (since controller is filtering) and the
     connection is never established.

So, to address this scenario, we should always restart background scan
to unsure we don't miss any advertising report (due to duplicates
filter).
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Different controllers behave differently when HCI_Set_Random_Address is
called while they are advertising or have a HCI_LE_Create_Connection in
progress. Some take the newly written address into use for the pending
operation while others use the random address that we had at the time
that the operation started.

Due to this undefined behavior and for the fact that we want to reliably
determine the initiator address of all connections for the sake of SMP
it's best to simply prevent the random address update if we have these
problematic operations in progress.

This patch adds a set_random_addr() helper function for the use of
hci_update_random_address which contains the necessary checks for
advertising and ongoing LE connections.

One extra thing we need to do is to clear the HCI_ADVERTISING flag in
the enable_advertising() function before sending any commands. Since
re-enabling advertising happens by calling first disable_advertising()
and then enable_advertising() all while having the HCI_ADVERTISING flag
set. Clearing the flag lets the set_random_addr() function know that
it's safe to write a new address at least as far as advertising is
concerned.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The random numbers in Bluetooth Low Energy are 64-bit numbers and should
also be little endian since the HCI specification is little endian.

Change the whole Low Energy pairing to use __le64 instead of a byte
array.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

The current LE white list entries require storing in the HCI controller
structure. So provide a storage and access functions for it. In addition
export the current list via debugfs.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

When starting up a controller make sure that all LE white list entries
are cleared. Normally the HCI Reset takes care of this. This is just
in case no HCI Reset has been executed.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

The hci_blacklist_clear function is not used outside of hci_core.c and
can be made static.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

The number of places needing the local Identity Address are starting to
grow so it's better to have a single place for the logic of determining
it. This patch adds a convenience function for getting the Identity
Address and updates the two current places needing this to use it.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patches creates the public hci_req_add_le_passive_scan helper so
it can be re-used outside hci_core.c in the next patch.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch adds to debugfs the le_auto_conn file. This file will be
used to test LE auto connection infrastructure.

This file accept writes in the following format:
  "add <address> <address_type> [auto_connect]"
  "del <address> <address_type>"
  "clr"

The <address type> values are:
  * 0 for public address
  * 1 for random address

The [auto_connect] values are (for more details see struct hci_
conn_params):
  * 0 for disabled (default)
  * 1 for always
  * 2 for link loss

So for instance, if you want the kernel autonomously establishes
connections with device AA:BB:CC:DD:EE:FF (public address) every
time the device enters in connectable mode (starts advertising),
you should run the command:
$ echo "add AA:BB:CC:DD:EE:FF 0 1" > /sys/kernel/debug/bluetooth/hci0/le_auto_conn

To delete the connection parameters for that device, run the command:
$ echo "del AA:BB:CC:DD:EE:FF 0" > /sys/kernel/debug/bluetooth/hci0/le_auto_conn

To clear the connection parameters list, run the command:
$ echo "clr" > /sys/kernel/debug/bluetooth/hci0/le_auto_conn

Finally. to get the list of connection parameters configured in kernel,
read the le_auto_conn file:
$ cat /sys/kernel/debug/bluetooth/hci0/le_auto_conn

This file is created only if LE is enabled.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

We should only accept connection parameters from identity addresses
(public or random static). Thus, we should check the address type
in hci_conn_params_add().

Additionally, since the IRK is removed during unpair, we should also
remove the connection parameters from that device.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

When hdev is closed (e.g. Mgmt power off command, RFKILL or controller
is reset), the ongoing active connections are silently dropped by the
controller (no Disconnection Complete Event is sent to host). For that
reason, the devices that require HCI_AUTO_CONN_ALWAYS are not added to
hdev->pend_le_conns list and they won't auto connect.

So to fix this issue, during hdev closing, we remove all pending LE
connections. After adapter is powered on, we add a pending LE connection
for each HCI_AUTO_CONN_ALWAYS address.

This way, the auto connection mechanism works propely after a power
off and power on sequence as well as RFKILL block/unblock.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

If the user sends a mgmt start discovery command while the background
scanning is running, we should temporarily stop it. Once the discovery
finishes, we start the background scanning again.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch modifies hci_conn_params_add() and hci_conn_params_del() so
they also add/delete pending LE connections according to the auto_
connect option. This way, background scan is automatically triggered/
untriggered when connection parameters are added/removed.

For instance, when a new connection parameters with HCI_AUTO_CONN_ALWAYS
option is added and we are not connected to the device, we add a pending
LE connection for that device.

Likewise, when the connection parameters are updated we add or delete
a pending LE connection according to its new auto_connect option.

Finally, when the connection parameter is deleted we also delete the
pending LE connection (if any).
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch introduces the LE auto connection options: HCI_AUTO_CONN_
ALWAYS and HCI_AUTO_CONN_LINK_LOSS. Their working mechanism are
described as follows:

The HCI_AUTO_CONN_ALWAYS option configures the kernel to always re-
establish the connection, no matter the reason the connection was
terminated. This feature is required by some LE profiles such as
HID over GATT, Health Thermometer and Blood Pressure. These profiles
require the host autonomously connect to the device as soon as it
enters in connectable mode (start advertising) so the device is able
to delivery notifications or indications.

The BT_AUTO_CONN_LINK_LOSS option configures the kernel to re-
establish the connection in case the connection was terminated due
to a link loss. This feature is required by the majority of LE
profiles such as Proximity, Find Me, Cycling Speed and Cadence and
Time.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch introduces the LE auto connection infrastructure which
will be used to implement the LE auto connection options.

In summary, the auto connection mechanism works as follows: Once the
first pending LE connection is created, the background scanning is
started. When the target device is found in range, the kernel
autonomously starts the connection attempt. If connection is
established successfully, that pending LE connection is deleted and
the background is stopped.

To achieve that, this patch introduces the hci_update_background_scan()
which controls the background scanning state. This function starts or
stops the background scanning based on the hdev->pend_le_conns list. If
there is no pending LE connection, the background scanning is stopped.
Otherwise, we start the background scanning.

Then, every time a pending LE connection is added we call hci_update_
background_scan() so the background scanning is started (in case it is
not already running). Likewise, every time a pending LE connection is
deleted we call hci_update_background_scan() so the background scanning
is stopped (in case this was the last pending LE connection) or it is
started again (in case we have more pending LE connections). Finally,
we also call hci_update_background_scan() in hci_le_conn_failed() so
the background scan is restarted in case the connection establishment
fails. This way the background scanning keeps running until all pending
LE connection are established.

At this point, resolvable addresses are not support by this
infrastructure. The proper support is added in upcoming patches.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch introduces the hdev->pend_le_conn list which holds the
device addresses the kernel should autonomously connect. It also
introduces some helper functions to manipulate the list.

The list and helper functions will be used by the next patch which
implements the LE auto connection infrastructure.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch moves stop LE scanning duplicate code to one single
place and reuses it. This will avoid more duplicate code in
upcoming patches.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>