With this patch kernel will be able to handle setup request. This is
needed if we would like to handle control mesages with extension
headers. User space will be only resposible for reading setup data and
checking if scenario is conformance to specification (dst and src device
bnep role). In case of new user space, setup data must be leaved(peek
msg) on queue. New bnep session will be responsible for handling this
data.
Signed-off-by: Grzegorz Kolodziejczyk <grzegorz.kolodziejczyk@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: bnep: Add support to extended headers of control frames
Handling extended headers of control frames is required BNEP
functionality. This patch refractor bnep rx frame handling function.
Extended header for control frames shouldn't be omitted as it was
previously done. Every control frame should be checked if it contains
extended header and then every extension should be parsed separately.
Signed-off-by: Grzegorz Kolodziejczyk <grzegorz.kolodziejczyk@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: bnep: Add support for get bnep features via ioctl
This is needed if user space wants to know supported bnep features
by kernel, e.g. if kernel supports sending response to bnep setup
control message. By now there is no possibility to know supported
features by kernel in case of bnep. Ioctls allows only to add connection,
delete connection, get connection list, get connection info. Adding
connection if it's possible (establishing network device connection) is
equivalent to starting bnep session. Bnep session handles data queue of
transmit, receive messages over bnep channel. It means that if we add
connection the received/transmitted data will be parsed immediately. In
case of get bnep features we want to know before session start, if we
should leave setup data on socket queue and let kernel to handle with it,
or in case of no setup handling support, if we should pull this message
and handle setup response within user space.
Signed-off-by: Grzegorz Kolodziejczyk <grzegorz.kolodziejczyk@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Disallow LE local out-of-band data when LE privacy is used
When the LE pivacy feature is used, then pairing has to happen based
on resolvable random addresses (RPA), but currently there is no clean
way to retrieve the correct RPA. So instead of returning an outdated
RPA, just disallow this command when LE privacy is in use.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Johan Hedberg [Thu, 2 Apr 2015 10:41:13 +0000 (13:41 +0300)]
Bluetooth: Convert local OOB data reading to use HCI request
Now that there's a HCI request API available where the callback receives
the resulting skb, we can convert the local OOB data reading to use this
new API. This patch does the necessary update in mgmt.c (which also
requires moving the callback higher up since it's now a static function)
and removes the custom calls from hci_event.c that are no-longer
necessary.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Thu, 2 Apr 2015 10:41:12 +0000 (13:41 +0300)]
Bluetooth: Move hci_get_cmd_complete() to hci_event.c
To make the hci_req_run_skb() API consistent with hci_cmd_sync_ev()
the callback should receive the cmd_complete parameters in the 'normal'
case and the full HCI event if a special event was expected. This patch
moves the hci_get_cmd_complete() function from hci_core.c to hci_event.c
where it's used to strip the skb from the needed headers before passing
it on to the callback.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Thu, 2 Apr 2015 10:41:10 +0000 (13:41 +0300)]
Bluetooth: Remove unneeded recv_event variable
Now that the synchronous HCI requests use the new API and a new private
variable the recv_evt member of hci_dev is no-longer needed. This patch
removes it.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Thu, 2 Apr 2015 10:41:09 +0000 (13:41 +0300)]
Bluetooth: Convert hci_req_sync family of function to new request API
Now that there's an API in place that allows passing the resulting skb
to the request callback we can conveniently convert the hci_req_sync and
related functions to use it. Since we still need to get the skb from the
async callback into the sleeping _sync() function the patch adds another
req_skb variable to hci_dev where the sync request state is tracked.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Thu, 2 Apr 2015 10:41:08 +0000 (13:41 +0300)]
Bluetooth: Add second hci_request callback option for full skb
This patch adds a second possible callback for HCI requests where the
callback will receive the full skb of the last successfully completed
HCI command. This API is useful for cases where we want to use a request
to read some data and the existing hci_event.c handlers do not store it
e.g. in the hci_dev struct.
The reason the patch is a bit bigger than just adding the new API is
because the hci_req_cmd_complete() functions required some refactoring
to enable it: now hci_req_cmd_complete() is simply used to request the
callback pointers if any, and the actual calling of them happens from a
single place at the end of hci_event_packet(). The reason for this is
that we need to pass the original skb (without any skb_pull, etc
modifications done to it) and it's simplest to keep track of it within
the hci_event_packet() function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Thu, 2 Apr 2015 10:41:07 +0000 (13:41 +0300)]
Bluetooth: Add clarifying comment to command status handling
When dealing with HCI command status events, the reasoning for trying to
mark a request as complete if no specific event is being waited for and
status was success is not self-evident. This patch adds a clarifying
comment above the if-statement.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When SMP selftest is enabled, then besides printing the result into the
kernel message buffer, also create a debugfs file that allows retrieving
the same information.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When ECDH selftest is enabled, then besides printing the result into the
kernel message buffer, also create a debugfs file that allows retrieving
the same information.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Johan Hedberg [Mon, 30 Mar 2015 20:21:02 +0000 (23:21 +0300)]
Bluetooth: Refactor HCI request variables into own struct
In order to shrink the size of bt_skb_cb, this patch moves the HCI
request related variables into their own req_ctrl struct. Additionall
the L2CAP and HCI request structs are placed inside the same union since
they will never be used at the same time for the same skb.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Mon, 30 Mar 2015 20:21:01 +0000 (23:21 +0300)]
Bluetooth: Refactor L2CAP variables into l2cap_ctrl
We're getting very close to the maximum possible size of bt_skb_cb. To
prepare to shrink the struct with the help of a union this patch moves
all L2CAP related variables into the l2cap_ctrl struct. To later add
other 'ctrl' structs the L2CAP one is renamed simple 'l2cap' instead
of 'control'.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Marcel Holtmann [Sat, 28 Mar 2015 22:18:59 +0000 (15:18 -0700)]
Bluetooth: Fix error returns for Read Local OOB Extended Data commands
The Read Local OOB Extended Data commands are required to return the
address type and the data length at least. However currently the error
returns only the address type.
To fix this and avoid any extra allocations or stack memory, rearrange
the code so that the same path can be used for error returns.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sat, 28 Mar 2015 22:18:58 +0000 (15:18 -0700)]
Bluetooth: Move memory location outside of hci_dev lock
Taking the hci_dev lock for just a memory allocation seems a bit too
much and not really needed. So instead try to allocate the memory first
and then take the lock.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Arman Uguray [Sat, 28 Mar 2015 19:39:00 +0000 (12:39 -0700)]
Bluetooth: Update adv. parameters when conn. setting changes
This patch fixes a bug where the advertising parameters weren't updated
after a call to "Set Connectable" if the HCI_ADVERTISING_INSTANCE
setting was set.
Arman Uguray [Sat, 28 Mar 2015 19:38:59 +0000 (12:38 -0700)]
Bluetooth: Use ADV_SCAN_IND for adv. instances
With this patch, ADV_SCAN_IND will be used for advertising instances
that have non-zero scan response data while the global "connectable"
setting is "off".
Johan Hedberg [Sat, 28 Mar 2015 09:17:36 +0000 (11:17 +0200)]
Bluetooth: Fix race condition with HCI_RESET flag
During the HCI init phase a completed request might be the last part of
the setup procedure after which the actual init procedure starts. The
init procedure begins with a call to hci_reset_req() which sets the
HCI_RESET flag. The purpose of this flag is to make us ignore any
updates to ncmd/cmd_cnt as long as we haven't received the command
complete event for the HCI_Reset. There's a potential race with this
however:
hci_req_cmd_complete(hdev, opcode, status);
if (ev->ncmd && !test_bit(HCI_RESET, &hdev->flags)) {
atomic_set(&hdev->cmd_cnt, 1);
if (!skb_queue_empty(&hdev->cmd_q))
queue_work(hdev->workqueue, &hdev->cmd_work);
}
Since the hci_req_cmd_complete() will trigger the completion of the
setup stage, it's possible that hci_reset_req() gets called before we
try to read ev->ncmd and the HCI_RESET flag. Because of this the cmd_cnt
would never be updated and the hci_reset_req() in practice ends up
blocking itself.
This patch fixes the issue by updating cmd_cnt before notifying the
request completion, and then reading it again to determine whether the
cmd_work should be queued or not.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Marcel Holtmann [Fri, 27 Mar 2015 22:11:41 +0000 (15:11 -0700)]
Bluetooth: btusb: Consolidate Broadcom based device entries
For all modern Bluetooth USB devices from Broadcom it makes a lot more
sense to use USB_VENDOR_AND_INTERFACE_INFO instead of manually adding
USB_DEVICE for each one of them. There are already interface entries
for these vendors and so just remove the duplicate device entries.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Alexander Aring [Thu, 26 Mar 2015 11:46:30 +0000 (12:46 +0100)]
at86rf230: fix is_tx while error handling
This patch fix the error handling when is_tx is true. The error handling
tries to get the transceiver into RX_AACK_ON mode then we need to be
sure that is_tx is false.
Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Alexander Aring [Thu, 26 Mar 2015 11:46:29 +0000 (12:46 +0100)]
at86rf230: remove unnecessary spinlock
This spinlock isn't necessary because if we are in TX_ON/TX_ARET_ON
state the transceiver can't be interrupted e.g. by receiving a frame
when a SHR was detected. In this time the transceiver doesn't leave
the TX_ON/TX_ARET_ON state until the tx complete irq change the state
into RX_AACK_ON again. This means a receiving interrupt in state
TX_ON/TX_ARET_ON can't happen and is_tx is protected by transceiver.
Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Arman Uguray [Thu, 26 Mar 2015 01:53:45 +0000 (18:53 -0700)]
Bluetooth: Update supported_flags for AD features
This patch updates the "supported_flags" parameter returned from the
"Read Advertising Features" command. Add Advertising will now return
an error if an unsupported flag is provided.
Loic Poulain [Wed, 25 Mar 2015 14:19:30 +0000 (15:19 +0100)]
Bluetooth: hci_uart: Add setup callback
Some Bluetooth controllers require initialization before being
used (vendor config, firmware download). Add possibility for a
HCI UART proto to implement this early init via the setup callback.
Marcel Holtmann [Wed, 25 Mar 2015 00:31:03 +0000 (17:31 -0700)]
Bluetooth: Filter list of supported commands/events for untrusted users
When the user of the management interface is not trusted, then it only
has access to a limited set of commands and events. When providing the
list of supported commands and events take the trusted vs untrusted
status of the user into account and return different lists.
This way the untrusted user knows exactly which commands it can
execute and which events it can receive. So no guesswork needed.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Arman Uguray [Mon, 23 Mar 2015 22:57:12 +0000 (15:57 -0700)]
Bluetooth: Implement the Add Advertising command
This patch adds the most basic implementation for the
"Add Advertisement" command. All state updates between the
various HCI settings (POWERED, ADVERTISING, ADVERTISING_INSTANCE,
and LE_ENABLED) has been implemented. The command currently
supports only setting the advertising data fields, with no flags
and no scan response data.
Arman Uguray [Mon, 23 Mar 2015 22:57:11 +0000 (15:57 -0700)]
Bluetooth: Add data structure for advertising instance
This patch introduces a new data structure to represent advertising
instances that were added using the "Add Advertising" mgmt command.
Initially an hci_dev structure will support only one of these instances
at a time, so the current instance is simply stored as a direct member
of hci_dev.
Arman Uguray [Mon, 23 Mar 2015 22:57:10 +0000 (15:57 -0700)]
Bluetooth: Introduce HCI_ADVERTISING_INSTANCE setting and add AD flags
This patch introduces the HCI_ADVERTISING_INSTANCE setting, which is set
when an at least one advertising instance has been added using the
"Add Advertising" mgmt command. This patch also adds a macro definition
for the EIR_APPEARANCE field type.
Marcel Holtmann [Sun, 22 Mar 2015 14:52:38 +0000 (15:52 +0100)]
Bluetooth: Read Broadcom chip info for Apple Bluetooth devices
For the Apple Bluetooth devices that are Broadcom based, it makes sense
to read the chip information. It is a single HCI command and might help
gathering more information about these devices.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Johan Hedberg [Sat, 21 Mar 2015 06:02:23 +0000 (08:02 +0200)]
Bluetooth: Fix memory leak in le_scan_disable_work_complete()
The hci_request in le_scan_disable_work_complete() was being initialized
in a general context but only used in a specific branch in the function
(when simultaneous discovery is not supported). This patch moves the
usage to be limited to the branch where hci_req_run() is actually
called.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Marcel Holtmann [Sat, 21 Mar 2015 00:16:36 +0000 (17:16 -0700)]
Bluetooth: Read Verbose Config Version Info for Broadcom devices
The Broadcom devices expose their chip id via Read Verbose Config
Version Info command. While this information is not used at the
moment, it might be useful for debugging purposes and so read it
before patching the firmware. This makes it show up in dmesg and
HCI traces taken for the system.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Jakub Pawlowski [Fri, 20 Mar 2015 18:14:50 +0000 (11:14 -0700)]
Bluetooth: Expose quirks through debugfs
This patch expose controller quirks through debugfs. It would be
useful for BlueZ tests using vhci. Currently there is no way to
test quirk dependent behaviour. It might be also useful for manual
testing.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Marcel Holtmann [Wed, 18 Mar 2015 23:15:07 +0000 (16:15 -0700)]
Bluetooth: Gracefully response to enabling LE on LE only devices
Currently the enabling of LE on LE only devices causes an error. This
is a bit difference from other commands where trying to set the same
existing settings causes a positive response. Fix this behavior for
this single corner case.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Brad Campbell [Tue, 17 Mar 2015 20:25:46 +0000 (16:25 -0400)]
cc2520: Add support for CC2591 amplifier.
The TI CC2521 is an RF power amplifier that is designed to interface
with the CC2520. Conveniently, it directly interfaces with the CC2520
and does not require any pins to be connected to a
microcontroller/processor. Adding a CC2591 increases the CC2520's range,
which is useful for border router and other wall-powered applications.
Using the CC2591 with the CC2520 requires configuring the CC2520 GPIOs
that are connected to the CC2591 to correctly set the CC2591 into TX and
RX modes. Further, TI recommends that the CC2520_TXPOWER and
CC2520_AGCCTRL1 registers are set differently to maximize the CC2591's
performance. These settings are covered in TI Application Note AN065.
This patch adds an optional `amplified` field to the cc2520 entry in the
device tree. If present, the CC2520 will be configured to operate with a
CC2591.
The expected pin mapping is:
CC2520 GPIO0 --> CC2591 EN
CC2520 GPIO5 --> CC2591 PAEN
Brad Campbell [Tue, 17 Mar 2015 20:25:45 +0000 (16:25 -0400)]
cc2520: Do not store platform_data in spi_device
Storing the `platform_data` struct inside of the SPI struct when using
the device tree allows for a later function to edit the content of that
struct. This patch refactors the `cc2520_get_platformat_data` function
to accept a pointer to a `cc2520_platform_data` struct and populates
the fields inside of it.
Marcel Holtmann [Tue, 17 Mar 2015 18:38:24 +0000 (11:38 -0700)]
Bluetooth: Fix potential NULL dereference in SMP channel setup
When the allocation of the L2CAP channel for the BR/EDR security manager
fails, then the smp variable might be NULL. In that case do not try to
free the non-existing crypto contexts
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Johan Hedberg [Sun, 15 Mar 2015 17:34:04 +0000 (19:34 +0200)]
Bluetooth: Add workaround for broken OS X legacy SMP pairing
OS X version 10.10.2 (and possibly older versions) doesn't support LE
Secure Connections but incorrectly copies all authentication request
bits from a Security Request to its Pairing Request. The result is that
an SC capable initiator (such as BlueZ) will think OS X intends to do SC
when in fact it's incapable of it:
< ACL Data TX: Handle 3585 flags 0x00 dlen 6
SMP: Security Request (0x0b) len 1
Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
> ACL Data RX: Handle 3585 flags 0x02 dlen 11
SMP: Pairing Request (0x01) len 6
IO capability: KeyboardDisplay (0x04)
OOB data: Authentication data not present (0x00)
Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
Max encryption key size: 16
Initiator key distribution: EncKey (0x01)
Responder key distribution: EncKey IdKey Sign (0x07)
< ACL Data TX: Handle 3585 flags 0x00 dlen 11
SMP: Pairing Response (0x02) len 6
IO capability: NoInputNoOutput (0x03)
OOB data: Authentication data not present (0x00)
Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
Max encryption key size: 16
Initiator key distribution: EncKey (0x01)
Responder key distribution: EncKey Sign (0x05)
The pairing eventually fails when we get an unexpected Pairing Confirm
PDU instead of a Public Key PDU:
It is only at this point that we can speculate that the remote doesn't
really support SC. This patch creates a workaround for the just-works
model, however the MITM case is unsolvable because the OS X user has
already been requested to enter a PIN which we're now expected to
randomly generate and show the user (i.e. a chicken-and-egg problem).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Tue, 17 Mar 2015 11:48:50 +0000 (13:48 +0200)]
Bluetooth: Move generic mgmt command dispatcher to hci_sock.c
The mgmt.c file should be reserved purely for HCI_CHANNEL_CONTROL. The
mgmt_control() function in it is already completely generic and has a
single user in hci_sock.c. This patch moves the function there and
renames it a bit more appropriately to hci_mgmt_cmd() (as it's a command
dispatcher).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Tue, 17 Mar 2015 11:48:49 +0000 (13:48 +0200)]
Bluetooth: Add hdev_init callback for HCI channels
In order to make the mgmt command handling more generic we can't have a
direct call to mgmt_init_hdev() from mgmt_control(). This patch adds a
new callback to struct hci_mgmt_chan. And sets it to point to the
mgmt_init_hdev() function for the HCI_CHANNEL_CONTROL instance.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Tue, 17 Mar 2015 11:48:48 +0000 (13:48 +0200)]
Bluetooth: Add generic mgmt helper API
There are several mgmt protocol features that will be needed by more
than just the current HCI_CHANNEL_CONTROL. These include sending generic
events as well as handling pending commands. This patch moves these
functions out from mgmt.c to a new mgmt_util.c file.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Tue, 17 Mar 2015 11:48:47 +0000 (13:48 +0200)]
Bluetooth: Add channel parameter to mgmt_pending_find() API
To be able to have pending commands for different HCI channels we need
to be able to distinguish for which channel a command was sent to. The
channel information is already part of the socket data and can be
fetched using the recently added hci_sock_get_channel() function. To not
require all mgmt.c code to pass an extra channel parameter this patch
also adds a helper pending_find() & pending_find_data() functions which
act as a wrapper to the new mgmt_pending_find() & mgmt_pending_find_data()
APIs.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Tue, 17 Mar 2015 11:48:46 +0000 (13:48 +0200)]
Bluetooth: Add helper to get HCI channel of a socket
We'll need to have access to which HCI channel a socket is bound to, in
order to manage pending mgmt commands in clean way. This patch adds a
helper for the purpose.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Jakub Pawlowski [Tue, 17 Mar 2015 16:04:14 +0000 (09:04 -0700)]
Bluetooth: Add simultaneous dual mode scan
When doing scan through mgmt api, some controllers can do both le and
classic scan at same time. They can be distinguished by
HCI_QUIRK_SIMULTANEOUS_DISCOVERY set.
This patch enables them to use this feature when doing dual mode scan.
Instead of doing le, then classic scan, both scans are run at once.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Some controllers allow both LE scan and BR/EDR inquiry to run at
the same time, while others allow only one, LE SCAN or BR/EDR
inquiry at given time.
Since this is specific to each controller, add a new quirk setting
that allows drivers to tell the core wether given controller can
do both LE scan and BR/EDR inquiry at same time.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This patch fix an issue when at86rf230_read_subreg was successful. The
function at86rf230_read_subreg will directly call regmap_read which
returns zero on successful. Nobody figured out issues yet because it was
only necessary to evaluate dvdd state while probing. This could make
trouble because the stack variable could have an random value.
The function is also used by reset the irq line before requesting irq, but
the value isn't evaluated afterwards.
Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Marcel Holtmann [Mon, 16 Mar 2015 23:11:21 +0000 (16:11 -0700)]
Bluetooth: Add support for Local OOB Extended Data Update events
When a different user requests a new set of local out-of-band data, then
inform all previous users that the data has been updated. To limit the
scope of users, the updates are limited to previous users. If a user has
never requested out-of-band data, it will also not see the update.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Mon, 16 Mar 2015 23:05:44 +0000 (16:05 -0700)]
Bluetooth: Fix length for Read Local OOB Extended Data respone packet
The length of the respone packet for Read Local OOB Extended Data
command has a calculation error. In case LE Secure Connections support
is not enabled, the actual response is shorter. Keep this in mind and
update the value accordingly.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Mon, 16 Mar 2015 19:39:00 +0000 (12:39 -0700)]
Bluetooth: Do not include LE SC out-of-band data if not enabled
In case LE Secure Connections is not enabled, then the command for
returning local out-of-band data should not include the confirmation
and random value for LE SC pairing. All other fields are still valid,
but these two need to be left out. In that case it is also no needed
to generate the public/private key pair for out-of-band pairing.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Mon, 16 Mar 2015 19:34:57 +0000 (12:34 -0700)]
Bluetooth: Rename smp->local_rr into smp->local_rand
The variable for the out-of-band random number was badly named and
with that confusing. Just rename it to local_rand so it is clear
what value it represents.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Johan Hedberg [Mon, 16 Mar 2015 19:12:34 +0000 (21:12 +0200)]
Bluetooth: Add clarifying comment when setting local OOB flag
It might be a bit counterintuitive to set a 'local' flag based on remote
data. This patch adds a clarifying comment to the pairing req/rsp
handlers when setting the LOCAL_OOB flag based on the PDU received from
the remote side.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Mon, 16 Mar 2015 16:12:57 +0000 (18:12 +0200)]
Bluetooth: Don't send public key if OOB data verification fails
When we receive the remote public key, if we have remote OOB data
there's no point in sending our public key to the remote if the OOB data
doesn't match. This patch moves the test for this higher up in the
smp_cmd_public_key() function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Mon, 16 Mar 2015 09:45:46 +0000 (11:45 +0200)]
Bluetooth: Fix verifying confirm value when lacking remote OOB data
If we haven't received remote OOB data we cannot perform any special
checks on the confirm value. This patch updates the check after having
received the public key to only perform the verification if we have
remote OOB data present.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Mon, 16 Mar 2015 09:45:45 +0000 (11:45 +0200)]
Bluetooth: Set local OOB data flag if remote has our OOB data
If the SMP Pairing Request or Response PDU received from the remote
device indicates that it has received our OOB data we should set the
SMP_FLAG_LOCAL_OOB flag.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Mon, 16 Mar 2015 09:45:44 +0000 (11:45 +0200)]
Bluetooth: Track local vs remote OOB data availability
There are several decisions in the SMP logic that depend not only on
whether we're doing SMP or not, but also whether local and/or remote OOB
data is present. This patch splits the existing SMP_FLAG_OOB into two
new flags to track local and remote OOB data respectively.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg [Mon, 16 Mar 2015 09:45:43 +0000 (11:45 +0200)]
Bluetooth: Fix local OOB data handling for SMP
We need to store the local ra/rb value in order to verify the Check
value received from the remote. This patch adds a new 'lr' for the local
ra/rb value and makes sure it gets used when verifying the DHKey Check
PDU received from the remote.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Marcel Holtmann [Mon, 16 Mar 2015 08:10:24 +0000 (01:10 -0700)]
Bluetooth: Use OOB key pair for LE SC pairing with OOB method
The OOB public and secret key pair is different from the non-OOB pairing
procedure. SO when OOB method is in use, then use this key pair instead
of generating a new one.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Mon, 16 Mar 2015 08:10:23 +0000 (01:10 -0700)]
Bluetooth: Return LE SC confirm and random values for out-of-band data
Then the local out-of-band data for LE SC pairing is requested via Read
Local OOB Extended Data command, then fill in the values generated by
the smp_generate_oob function. Every call of this command will overwrite
previously generated values.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Mon, 16 Mar 2015 08:10:22 +0000 (01:10 -0700)]
Bluetooth: Add function for generating LE SC out-of-band data
This patch adds a smp_generate_oob function that allows to create
local out-of-band data that can be used for pairing and also provides
the confirmation and random value.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Mon, 16 Mar 2015 08:10:21 +0000 (01:10 -0700)]
Bluetooth: Add support for AES-CMAC hash for security manager device
The security manager device will require the use of AES-CMAC hash for
out-of-band data generation. This patch makes sure it is correctly
set up and available.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Mon, 16 Mar 2015 08:10:20 +0000 (01:10 -0700)]
Bluetooth: Add constants for LE SC Confirmation and Random values
The LE Secure Connections Confirmation Value and LE Secure Connections
Random Value contants are required for the out-of-band data and so
just define them.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Mon, 16 Mar 2015 08:10:19 +0000 (01:10 -0700)]
Bluetooth: Create SMP device structure for local crypto context
Every Bluetooth Low Energy controller requires a local crypto context
to handle the resolvable private addresses. At the moment this is just
a single crypto context, but for out-of-band data generation it will
require an additional. To facility this, create a struct smp_dev that
will hold all the extra information. This patch is just the refactoring
in preparation for future changes.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Mon, 16 Mar 2015 08:10:18 +0000 (01:10 -0700)]
Bluetooth: Use kzfree instead of kfree in security manager
Within the security manager, it makes sense to use kzfree instead of
kfree for all data structures. This ensures that no key material leaks
by accident.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Mon, 16 Mar 2015 00:08:19 +0000 (17:08 -0700)]
Bluetooth: Remove unneeded HCI_CONN_REMOTE_OOB connection flag
The HCI_CONN_REMOTE_OOB connection flag is used to indicate if the
pairing initiator has provided out-of-band data. However since that
value is no longer used in any decision making, just remove it.
It is actually unclear what purpose the OOB data present field from
the HCI IO Capability Response event serves in the first place. If
either side provided out-of-band data, then that data will be used
for pairing.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 15 Mar 2015 23:42:53 +0000 (16:42 -0700)]
Bluetooth: Fix BR/EDR out-of-band pairing with only initiator data
When only the pairing initiator is providing out-of-band data, then
the receiver side was ignoring the data. For some reason the code was
checking if the initiator has received out-of-band data and only then
also provide the required inidication that the acceptor actually has
the needed data available.
For BR/EDR out-of-band pairing it is enough if one side has received
out-of-band data. There are no extra checks needed here to make this
work smoothly. The only thing that is needed is to tell the controller
if data is present (and if it is P-192 or P-256 or both) and then let
the controller actually figure out the rest.
This means the check for outgoing connection or if the initiator has
indicated data are completely pointless and are in fact actually
causing harm. The check in question is this one:
if (conn->out || test_bit(HCI_CONN_REMOTE_OOB, &conn->flags)) {
After just taking the conditional check out and always executing the
code for determining the type of out-of-band data, the pairing works
flawlessly and prodcudes authenticated link keys.
The patch itself looks more complicated due to the reformatting of the
indentation, but it essentially just a two-line change.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 15 Mar 2015 05:43:19 +0000 (22:43 -0700)]
Bluetooth: Add simple version of Read Local OOB Extended Data command
This adds support for the simplest possible version of Read Local OOB
Extended Data management command. It includes all mandatory fields,
but none of the actual pairing related ones.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
projects / linux-beck.git / log