Enabling passive scanning always when we're connectable aligns us with
the BR/EDR page scanning. This is also consistent with the fact that the
code dealing with passive scanning results will actively try to connect
any direct advertising event when we're connectable.
This patch implements the feature by adding the connectable condition to
hci_update_background_scan() checks for starting scanning and by calling
hci_update_background_scan() whenever the connectable state changes.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Mon, 7 Jul 2014 10:24:59 +0000 (13:24 +0300)]
Bluetooth: Don't let background scanning interfering with discovery
If we have an active discovery going on we shouldn't do any changes to
LE scanning when hci_update_background_scan() is called (a call which
can happen for many different reasons). This patch fixes the issue by
returning from the function if the discovery state is anything else
except DISCOVERY_STOPPED.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Mon, 7 Jul 2014 10:24:58 +0000 (13:24 +0300)]
Bluetooth: Update discovery state earlier in hci_discovery_set_state
In a subsequent patch the hci_update_background_scan() function will
depend on being able to know the current discovery state. For this to be
possible we need to set the new state early in the function. Since we
also need to check what the old state was this patch introduces an extra
variable for tracking it.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Mon, 7 Jul 2014 09:45:54 +0000 (12:45 +0300)]
Bluetooth: Remove redundant IRK lookup in mgmt_device_found()
Now that we have the process_adv_report() function doing the IRK lookup
and updating the bdaddr we don't need to do this anymore in mgmt.c in
the mgmt_device_found() function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Mon, 7 Jul 2014 09:45:53 +0000 (12:45 +0300)]
Bluetooth: Fix connecting devices during LE device discovery
If we have devices set as to be connected we should connect to them even
during normal discovery if we get a connectable advertising event. If we
also have HCI_CONNECTABLE set we should connect ADV_DIRECT_IND events
even to devices that we don't have in our pend_le_conns list. This patch
implements such behavior by passing the advertising report type to
check_pending_le_conn() and calls that function regardless of what type
of scanning we are doing.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The hdev->send driver callback is mandatory to be provided by a driver
before calling hci_register_dev. So enforce it and return EINVAL in
case it is not available.
All existing drivers are providing this callback anyway, so this is
just an extra sanity check.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Fix memory leaking when hdev->send returns an error
The drivers are allowed to just return an error from hdev->send callback
and in that case the driver does not own the SKB. Which means that the
caller has to free the SKB.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Ignore isochronous endpoints for Intel USB bootloader
The isochronous endpoints are not valid when the Intel Bluetooth
controller boots up in bootloader mode. So just mark these endpoints
as broken and then they will not be configured.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Handle Intel USB bootloader with buggy interrupt
The interrupt interface for the Intel USB bootloader devices is only
enabled after receiving SetInterface(0, AltSetting=0). When this USB
command is not send, then no HCI events will be received.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Johan Hedberg [Sun, 6 Jul 2014 12:44:23 +0000 (15:44 +0300)]
Bluetooth: Fix updating background scan for LE connect complete
When we get an LE connection complete event we should restart background
scanning if there are any devices needing it. So far the code was only
making the decision based on whether the completed connection had any
stored parameters or not. This patch ensures that we trigger background
scanning always when necessary.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Skip unconfigured init procedure for raw-only devices
When the driver sets HCI_QUIRK_RAW_DEVICE, the controller will be set
as unconfigured. However running the unconfigured init procecure is
not useful since raw-only devices are not allowed to change its
configuration. This change skips the init procedure and just allows
user channel operation for this device.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Add support for Intel bootloader devices
Intel Bluetooth devices that boot up in bootloader mode can not
be used as generic HCI devices, but their HCI transport is still
valuable and so bring that up as raw-only devices.
Johan Hedberg [Sun, 6 Jul 2014 10:41:15 +0000 (13:41 +0300)]
Bluetooth: Use lower timeout for LE auto-connections
When we establish connections as a consequence of receiving an
advertising report it makes no sense to wait the normal 20 second LE
connection timeout. This patch modifies the hci_connect_le function to
take an extra timeout value and uses a lower 2 second timeout for the
auto-connection case. This timeout is intentionally chosen to be just a
bit higher than the 1.28 second timeout that High Duty Cycle Advertising
uses.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Clear HCI_RAW flag when controller becomes configured
When an unconfigured controllers reaches the configured state, it is
important to change the HCI_RAW flag. It indicates to userspace that
the controller is fully operational.
External configuration allows to bring the controller back into an
unconfigured state. In that case make sure HCI_RAW flag is set again.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Add support for changing the public device address
This adds support for changing the public device address. This feature
is required by controllers that do not provide a public address and
have HCI_QUIRK_INVALID_BDADDR set.
Even if a controller has a public device address, this is useful when
an embedded system wants to use its own value. As long as the driver
provides the set_bdaddr callback, this allows changing the device
address before powering on the controller.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Run controller setup after external configuration
When the external configuration triggers the switch to a configured
controller, it means the setup needs to be run. Controllers that start
out unconfigured have only run limited set of HCI commands. This is
not enough for complete operation and thus run the setup procedure
before announcing the new controller index.
This introduces HCI_CONFIG flag as companion to HCI_SETUP flag. The
HCI_SETUP flag is only used once for the initial setup procedure. And
during that procedure hdev->setup driver callback is called. With the
new HCI_CONFIG the switch from unconfigured to configured state is
triggering the same setup procedure just without hdev->setup. This
is required since bringing a controller back to unconfigured state
from configured state is possible.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Johan Hedberg [Sun, 6 Jul 2014 10:06:51 +0000 (13:06 +0300)]
Bluetooth: Fix sending Device Removed when clearing all parameters
When calling Device Remove with BDADDR_ANY we should in a similar way
emit Device Removed events as we do when removing a single device. Since
we have to iterate the list and call device_removed() the dedicated
hci_conn_params_clear_enabled() is not really useful anymore. This patch
removes the helper function and does the event emission and list item
removal in a single loop.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Sun, 6 Jul 2014 08:03:36 +0000 (11:03 +0300)]
Bluetooth: Restrict blocked device check in l2cap_recv_frame to LE
BR/EDR has the connection request and connection request rejection, but
LE doesn't have anything similar. We still request LE connections to
blocked devices to be disconnected but it's possible that ACL data slips
through before that. The check in l2cap_recv_frame really only needs to
be for LE and not BR/EDR because of this.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Store Bluetooth address from controller setup
During the setup phase of a controller, the Bluetooth address will be
read and to have that original address available for later use, store
it as setup address.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Run special init procedure for unconfigured controllers
For an unconfigured controller it is required to read at least the
local version information. If the set_bdaddr driver callback is
provideded, then also the local Bluetooth address will be read.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Use a more simpler style for HCI event callbacks
The HCI event callbacks have grown over the last years and some
functions handle status checking different than others. For the
simple ones, check the status at the beginning and exit if an
error with the HCI command occured.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Add support for Set External Configuration management command
The Set External Configuration management command allows for switching
between configured and unconfigured start if HCI_QURIK_EXTERNAL_CONFIG
is set by the transport driver.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Support HCI_QUIRK_EXTERNAL_CONFIG for hci_vhci driver
This adds support for configuring the hci_vhci virtual controllers
to require a setup stage using HCI_QUIRK_EXTERNAL_CONFIG. With this
option the virtual controller will start out as unconfigured.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Fix quirks that are valid during setup driver callback
For the quirks that are allow to be set during setup callback, the
check needs to be modified so that they are applied even if no
setup callback provided by the driver.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Allow reading configuration info when unconfigured
Reading the controller configuration information is a valid management
command when the controller is unconfigured. Allow this command, but
return invalid index on all other commands.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Add quirk for invalid controller address setting
When a Bluetooth controller does not have a valid public Bluetooth
address, then allow the driver to indicate this. If the quirk is
set, the Bluetooth core will switch to unconfigured state first
and will allow userspace to configure the address before starting
the full initialization of the controller.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The current existing device quirks are not documented. So instead of
spreading bits and pieces somewhere in the code, add proper comments
on where these quirks can be used and what behavior they change.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Fix constant for public address configuration
The public address configuration option is value 0x02 since the generic
external configuration is value 0x01. So adjust this accordingly and
also add the value 0x01 to the list.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Johan Hedberg [Fri, 4 Jul 2014 09:37:27 +0000 (12:37 +0300)]
Bluetooth: Use hci_pend_le_action_lookup to look up report entries
Instead of looking through the entire list of entries we can more
efficiently use the new hci_pend_le_action_lookup() function to look up
entries specifically in the pend_le_reports list. Since the search is
now limited to the right list we can also remove an unnecessary check
for list_empty() before the lookup.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Fri, 4 Jul 2014 09:37:26 +0000 (12:37 +0300)]
Bluetooth: Make hci_pend_le_conn_lookup more general purposed
In some circumstances we need to look up entries in pend_le_conns and in
other in pend_le_reports. This patch converts the existing lookup
function for pend_le_conns to something that can be used for both lists.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Fri, 4 Jul 2014 09:37:23 +0000 (12:37 +0300)]
Bluetooth: Fix clearing and restarting all LE actions on power cycle
When powering off (hci_dev_do_close) we should clear both the
pend_le_reports and pend_le_conns types of entries. When powering on
respectively we should populate both lists. This patch converts the
hci_pend_le_conns_clear() function into hci_pend_le_actions_clear()
(which can now be static) and converts the restart_le_auto_conns()
function into restart_le_actions().
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Fri, 4 Jul 2014 09:37:21 +0000 (12:37 +0300)]
Bluetooth: Simplify hci_conn_params->action list usage
Since params->action is used for both the pend_le_conns and
pend_le_reports lists we can simplify the adding and deleting of the
lists considerably. For example, when deleting entries in most
situations we no-longer need to check the auto_connect value but can
directly proceed with calling list_del_init on param->action (which is
safe even if the entry is not part of any list).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Fri, 4 Jul 2014 09:37:20 +0000 (12:37 +0300)]
Bluetooth: Don't bother doing anything if auto_connect doesn't change
When hci_conn_params_set() is called if the new auto_connect value is
the same as the old one we don't need to take any action. Simply return
success from the function in this case.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Fri, 4 Jul 2014 09:37:19 +0000 (12:37 +0300)]
Bluetooth: Simplify use of hci_pend_le_conns_clear()
Now that pend_le_connections is a list of hci_conn_params entries we can
simply remove items from that list as we iterate through the global list
of le_conn_params. This also moves the responsibility of calling
hci_update_background_scan() to the functions that were previously
calling hci_pend_le_conns_clear(). The only user that's left for
hci_pend_le_conns_clear() is hci_dev_do_close() which anyway does not
need to call hci_update_background_scan().
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Fri, 4 Jul 2014 09:37:18 +0000 (12:37 +0300)]
Bluetooth: Convert pend_le_reports into a list
To simplify manipulation and lookup of hci_conn_params entries of the
type HCI_AUTO_CONN_REPORT it makes sense to store them in their own
list. The new action list_head in hci_conn_params is used for this
purpose.
Johan Hedberg [Fri, 4 Jul 2014 09:37:17 +0000 (12:37 +0300)]
Bluetooth: Convert pend_le_conn list to a generic action list
In preparation to store also HCI_AUTO_CONN_REPORT entries in a list it
makes sense to convert the existing pend_le_conn list head of
hci_conn_params into a more generically named "action". This makes sense
because a parameter entry will never participate in more than one action
list.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Fri, 4 Jul 2014 09:37:16 +0000 (12:37 +0300)]
Bluetooth: Fix missing return statement in process_adv_report
If we're doing passive scanning we shouldn't proceed with any of the
code that deals with active scanning (pending reports, etc.). This patch
fixes a missing return statement for the passive scanning section in the
process_adv_report() function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Add support for controller configuration info command
The Read Controller Configuration Information command allows retrieving
details about possible configurations option. The supported options are
returned and also the missing options (if any).
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Johan Hedberg [Thu, 3 Jul 2014 16:33:51 +0000 (19:33 +0300)]
Bluetooth: Add identity address check in param lookup functions
Since we only store entries with identity addresses in the
le_conn_params and pend_le_conns lists we can avoid unnecessary lookups
by checking for an identity address before diving into the lists
themselves.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Thu, 3 Jul 2014 16:33:50 +0000 (19:33 +0300)]
Bluetooth: Remove unnecessary checks for auto-connected devices
If a device is in the pend_le_conns list it cannot at the same time also
have the need to be notified through mgmt_device_found. By making
check_pending_le_conn return whether it found an entry or not we can
avoid unnecessary checks in process_adv_report().
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Thu, 3 Jul 2014 16:33:49 +0000 (19:33 +0300)]
Bluetooth: Use hci_conn_params in pend_le_conns
Since the connection parameters are always a basis for adding entries to
hdev->pend_le_conns (so far of type bdaddr_list) it's simpler and more
efficient to have the parameters themselves be the entries in the
pend_le_conns list. We do this by adding another list_head to the
hci_conn_params struct.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Thu, 3 Jul 2014 16:33:48 +0000 (19:33 +0300)]
Bluetooth: Remove redundant IRK lookup
When processing passive scanning results we need the resolved identity
address both in check_pending_le_conn() as well as later in
process_adv_report(). Since process_adv_report() calls
check_pending_le_conn() we can simply resolve the IRK earlier in the
function and thereby eliminate a second lookup.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Thu, 3 Jul 2014 16:33:47 +0000 (19:33 +0300)]
Bluetooth: Fix missing update of pend_le_reports
When calling Remove Device for an entry using HCI_AUTO_CONN_REPORT we
need to decrement the pend_le_reports value correspondingly. This patch
fixes one such missing action in the Remove Device command handler.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Thu, 3 Jul 2014 10:52:27 +0000 (13:52 +0300)]
Bluetooth: Fix buffer overflow with variable length commands
The handler for variable length commands were trying to calculate the
expected length of the command based on the given parameter count, and
then comparing that with the received data. However, the expected count
was stored in a u16 which can easily overflow. With a carefully crafted
command this can then be made to match the given data even though the
parameter count is actually way too big, resulting in a buffer overflow
when parsing the parameters.
This patch fixes the issue by calculating a per-command maximum
parameter count and returns INVALID_PARAMS if it is exceeded.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Wed, 2 Jul 2014 20:09:24 +0000 (23:09 +0300)]
Bluetooth: Support scanning for devices using RPA
When we're scanning for specific devices that use an RPA we need to
convert the RPA to the identity address before looking up the entry in
the connection parameters. This patch adds the necessary code to do this
in the process_adv_report() function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Wed, 2 Jul 2014 19:42:02 +0000 (22:42 +0300)]
Bluetooth: Add support for background LE scanning
If we have one or more devices with HCI_AUTO_CONN_REPORT we should do
background scanning and emit mgmt_device_found events. This patch
modifies the hci_update_background_scan() function to extend the
conditions needed to trigger scanning, and adds the necessary code to
process_adv_report() to emit mgmt_device_found events.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Wed, 2 Jul 2014 19:42:01 +0000 (22:42 +0300)]
Bluetooth: Allow mgmt_device_found events for kernel-side scanning
When the kernel is doing LE scanning because of one or more devices
added with action 0x00 through the Add Device command we do want to let
mgmt_device_found() to proceed with sending an event. This kind of
devices are tracked with hdev->pend_le_reports, so check this value
before bailing out from the function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Wed, 2 Jul 2014 19:42:00 +0000 (22:42 +0300)]
Bluetooth: Track number of added devices with HCI_AUTO_CONN_REPORT
To be able to make the right choice of whether to start passive scanning
or to send out a mgmt_device_found event we need to know if there are
any devices in the le_conn_params list with the auto_connect value set
to HCI_AUTO_CONN_REPORT. This patch adds a counter for this kind of
devices.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Support HCI_QUIRK_RAW_DEVICE for hci_vhci driver
This adds support for configuring the hci_vhci virtual controllers
as a raw-only device using HCI_QUIRK_RAW_DEVICE. This is useful for
testing the kernel internal infrastructure.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Add support for Unconfigured Index Added events
When a controller is in unconfigured state it is currently hidden
from the management interface. This change now announces the new
controller with an Unconfigured Index Added event and allows clients
to easily detect the controller.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Introduce unconfigured controller state
With the new unconfigured controller state it is possible to provide a
fully functional HCI transport, but disable the higher level operations
that would normally happen. This way userspace can try to configure the
controller before releases the unconfigured state.
The internal state is represented by HCI_UNCONFIGURED. This replaces the
HCI_QUIRK_RAW_DEVICE quirk as internal state representation. This is now
a real state and drivers can use the quirk to actually trigger this
state. In the future this will allow a more fine grained switching from
unconfigured state to configured state for controller inititialization.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Johan Hedberg [Wed, 2 Jul 2014 14:37:34 +0000 (17:37 +0300)]
Bluetooth: Don't send connection parameters without identity address
If we don't have an identity address for connection parameters it
doesn't really make sense to send them to user space. Instead just
ignore them for now. Later we can add support for sending them when we
eventually get the identity through pairing.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Wed, 2 Jul 2014 14:37:33 +0000 (17:37 +0300)]
Bluetooth: Make is_identity_address a global function
There are more places that can take advantage of is_identity_address()
besides hci_core.c. This patch moves the function to hci_core.h and
gives it the appropriate hci_ prefix.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Wed, 2 Jul 2014 14:37:32 +0000 (17:37 +0300)]
Bluetooth: Pass store hint to mgmt_new_conn_param
The calling functions of mgmt_new_conn_param have more information about
the parameters, such as whether the kernel is tracking them or not. It
makes therefore sense to have them pass an initial store_hint value to
the mgmt_new_conn_param function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Wed, 2 Jul 2014 14:37:31 +0000 (17:37 +0300)]
Bluetooth: Make hci_le_conn_update return the store hint
The caller of hci_le_conn_update is directly interested in knowing what
the best value is for the store_hint parameter of the corresponding
mgmt event. Since hci_le_conn_update knows whether there were stored
parameters that were updated or not we can have it return an initial
store_hint value to the caller.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Wed, 2 Jul 2014 14:37:30 +0000 (17:37 +0300)]
Bluetooth: Fix missing update of conn params
We should update any stored connection parameters when we receive the LE
Remote Connection Parameter Request HCI event. This patch adds the
necessary code to the function that handles the event.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Wed, 2 Jul 2014 14:37:28 +0000 (17:37 +0300)]
Bluetooth: Remove only enabled entries with Remove Device command
The Remove Device mgmt command is supposed to undo what the Add Device
command does. An entry added by Add Device cannot have the
HCI_AUTO_CONN_DISABLED auto_connect value, so we should treat this as an
invalid entry to remove. This patch adds the necessary pieces to the
Remove Device command handler so that it only removes entries which were
added by Add Device.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Wed, 2 Jul 2014 14:37:26 +0000 (17:37 +0300)]
Bluetooth: Add specific connection parameter clear functions
In some circumstances we'll need to either clear only the enabled
parameters or only the disabled ones. This patch adds convenience
functions for this purpose.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Check for default address of Broadcom BCM20702A0 controllers
The Broadcom BCM20702A0 USB controllers might come with the default
address 00:20:70:02:A0:00 when booting up. If this happens, then warn
about such address being used.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Check for default address of Intel USB controllers
Some Intel Bluetooth controllers come with a default address. If this
address is found, print an error to warn the user about it.
The controller is fully operational, but the danger of duplicate
Bluetooth addresses might causes issues. At least with a clear
error it becomes easier to debug these cases.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Default to internal use manufacturer identifier
When allocating a new controller structure, then default to the internal
use value 0xffff first. Default to 0x0000 is a bad idea since that is
the manufacturer identifier of Ericsson Technology Licensing.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Johan Hedberg [Wed, 2 Jul 2014 06:36:22 +0000 (09:36 +0300)]
Bluetooth: Drop LE connections for blocked devices
Unlike BR/EDR we cannot reject LE connections of blocked devices but
have to do it as soon as we get a LE Connection Complete event. The
patch adds a blacklist check to the hci_le_conn_complete_evt function
and drops all connections for blocked devices.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Wed, 2 Jul 2014 06:36:21 +0000 (09:36 +0300)]
Bluetooth: Centralize looking up blocked devices to l2cap_recv_frame
The ATT channel isn't the only one that we should ensure doesn't receive
data from blocked devices. SMP is another, and in general we don't want
data packets going to any of the various handlers. Therefore, add a
single check to the l2cap_recv_frame function.
The patch fixes at the same time the use of a correct address type. The
blacklist stores the values with the user space facing triple type
wheras hci_conn->dst_type uses the HCI address type (0x00 or 0x01).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Andre Guedes [Tue, 1 Jul 2014 21:10:11 +0000 (18:10 -0300)]
Bluetooth: Introduce "New Connection Parameter" Event
This patch introduces a new Mgmt event called "New Connection Parameter".
This event indicates to userspace the connection parameters values the
remote device requested.
The user may store these values and load them into kernel. This way, next
time a connection is established to that device, the kernel will use those
parameters values instead of the default ones.
This event is sent when the remote device requests new connection
parameters through connection parameter update procedure. This event is
not sent for slave connections.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Andre Guedes [Tue, 1 Jul 2014 21:10:10 +0000 (18:10 -0300)]
Bluetooth: Enable new LE meta event
The Bluetooth 4.1 introduces a new LE meta event called "LE Remote
Connection Parameter Request" event. In order to the controller
sends this event to host, we should enable it during controller
initialization.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Andre Guedes [Tue, 1 Jul 2014 21:10:09 +0000 (18:10 -0300)]
Bluetooth: Move LE event mask setting into init3 phase
During init2 phase, the LE local features have not be read yet so
we aren't able to rely on hdev->le_features to determine if the
controller supports the Connection Parameters Request Procedure.
For that reason, this patch moves LE event mask setting from init2
into init3 initialization phase.
The hdev->le_features mask will be checked by the next patch in order
to know if "LE Remote Connection Parameter Request Event" should be
enabled.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Andre Guedes [Tue, 1 Jul 2014 21:10:08 +0000 (18:10 -0300)]
Bluetooth: Connection Parameter Update Procedure
This patch adds support for LE Connection Parameters Request Link
Layer control procedure introduced in Core spec 4.1. This procedure
allows a Peripheral or Central to update the Link Layer connection
parameters of an established connection.
Regarding the acceptance of connection parameters, the LL procedure
follows the same approach of L2CAP procedure (see l2cap_conn_param_
update_req function). We accept any connection parameters values as
long as they are within the valid range.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Chin-Ran Lo [Tue, 1 Jul 2014 21:00:14 +0000 (14:00 -0700)]
Bluetooth: btmrvl: wait for HOST_SLEEP_ENABLE event in suspend
After BT_CMD_HOST_SLEEP_ENABLE command finishes, driver should
wait until getting BT_EVENT_HOST_SLEEP_ENABLE event to complete
suspend procedure.
Without this patch the suspend handler would return success
earlier. By the time when the BT_EVENT_HOST_SLEEP_ENABLE event
comes in the controller driver could have already turned off the
bus clock. This causes kernel crash or system reboot eventually.
For the Block/Unblock Device mgmt commands we should only emit the
Blocked/Unblocked events on any socket except for the one which received
the command. The code was previously incorrectly trying to look up a
non-existent pending command and thereby ending up not skipping the
command socket for the event.
We can simplify the code a lot by simply sending the event directly from
the command handler functions. We have the reference to the command
socket available there which makes it easy to pass to the mgmt_event
function for skipping.
The only notable side-effect of this is that the old blacklisting
ioctl's no-longer cause mgmt events to be emitted, however as user space
versions using these ioctl's are not mgmt-aware this is acceptable.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Ensure that background scanning gets enabled on power on
The background scanning normally gets enabled during power on by
adding devices to the pending connection list. However devices
might be already on that list and the list of devices is empty,
then it is better to trigger the background manually.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Do not trigger background scanning when HCI_AUTO_OFF is set
When a new controller is initialized, but not powered from userspace
at the moment, the HCI_AUTO_OFF flag is still set. During this period,
userspace might program device for auto-connection, but never power
on the controller. In this case do not try to start background
scanning and leave it for later to be started.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Johan Hedberg [Tue, 1 Jul 2014 16:14:13 +0000 (19:14 +0300)]
Bluetooth: Allow re-encryption with LTK when STK is in use
If we're encrypted with the STK we should allow re-encryption with an
LTK even though the achieved security level is the same. This patch adds
the necessary logic to the smp_sufficient_security function which is
used to determine whether to proceed with encryption or not.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Tue, 1 Jul 2014 16:14:12 +0000 (19:14 +0300)]
Bluetooth: Add flag to track STK encryption
There are certain subtle differences in behavior when we're encrypted
with the STK, such as allowing re-encryption even though the security
level stays the same. Because of this, add a flag to track whether we're
encrypted with an STK or not.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Tue, 1 Jul 2014 15:40:20 +0000 (18:40 +0300)]
Bluetooth: Fix redundant encryption when receiving Security Request
If we're already encrypted with a good enough LTK we should just ignore
an incoming SMP Security Request. The code was already taking care of
this in the smp_conn_security function before calling smp_ltk_encrypt
but failed to do the same in smp_cmd_security_req. This patch fixes the
issue by moving up the smp_sufficient_security function and using it in
the Security Request handler before trying to request encryption.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Add support for Not Connectable flag for Device Found events
The Device Found events of the management interface should indicate if
it is possible to connect to a remote device or if it is broadcaster
only advertising. To allow this differentation the Not Connectable flag
is introduced that will be set when it is known that a device can not
be connected.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Provide flags parameter direct to mgmt_device_found
Providing the flags parameter directly to mgmt_device_found function
makes the core simpler and more readable. With this it becomes a lot
easier to add new flags in the future.
This also changes hci_inquiry_cache_update to just return that flags
needed for mgmt_device_found since that is its only use for the two
return parameters anyway.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Bluetooth: Fix merge of advertising data and scan response data
The advertising data and scan response data are merged in the wrong
order. It should be advertsing data first and then scan response data
and not the other way around.
projects / linux-beck.git / log