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>
Marcel Holtmann [Sun, 15 Mar 2015 02:28:05 +0000 (19:28 -0700)]
Bluetooth: Send global configuration updates to all management users
Changes to the global configuration updates like settings, class of
device, name etc. can be received by every user. They are allowed to
read them in the first place so provide the updates via events as
well. Otherwise untrusted users start polling for updates and that
is not a desired behavior.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 15 Mar 2015 02:28:04 +0000 (19:28 -0700)]
Bluetooth: Open management interface for untrusted users
Until now the management interface was restricted to CAP_NET_ADMIN. With
this change every user can open the management socket. However the list
of commands is heavily restricted to getting basic information about the
attached controllers. No access for configuration or other operation is
provided. The events are also limited. This is done so that no keys can
leak or untrusted users can mess with the Bluetooth configuration.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 15 Mar 2015 02:28:03 +0000 (19:28 -0700)]
Bluetooth: Add support for trust verification of management commands
Check the required trust level of each management command with the trust
level of the management socket. If it does not match up, then return the
newly introduced permission denied error.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 15 Mar 2015 02:28:01 +0000 (19:28 -0700)]
Bluetooth: Add support for untrusted access to management commands
Some management commands are safe to be accessed from any user without
special permissions. First step for allowing access to any of these
commands from untrusted application is to mark them accordingly.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 15 Mar 2015 02:27:59 +0000 (19:27 -0700)]
Bluetooth: Consolidate socket channel sending function back into one
With the introduction of trusted socket flag for control and monitor
channels, it is now possible to use a single function for sending
packets to these sockets. And with that consolidate the handling.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 15 Mar 2015 02:27:58 +0000 (19:27 -0700)]
Bluetooth: Introduce trusted flag for management control sockets
Providing a global trusted flag for management control sockets provides
an easy way for identifying sockets and imposing restriction on it. For
now all management sockets are trusted since they require CAP_NET_ADMIN.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 15 Mar 2015 02:27:57 +0000 (19:27 -0700)]
Bluetooth: Add support for extended index management command
The Read Extended Contoller Index List command can be used for
retrieving the complete list of local available controllers. This
included configured, unconfigured and also AMP controllers.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 15 Mar 2015 02:27:56 +0000 (19:27 -0700)]
Bluetooth: Add support for extended index management events
This introduces support for using Extended Index Added and Extended
Index Removed events. These events contain the controller type and
also the hardware bus information from the driver.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 15 Mar 2015 02:27:55 +0000 (19:27 -0700)]
Bluetooth: Use special function to send filter management index events
For sending Index Added, Index Removed, Unconfigured Index Added and
Unconfigured Index Removed managment events the new helper functions
allows taking into account if these events are enabled for a certain
management socket or not.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Marcel Holtmann [Sun, 15 Mar 2015 02:27:54 +0000 (19:27 -0700)]
Bluetooth: Provide hci_send_to_flagged_channel helper function
The hci_send_to_flagged_channel helper function can be used to send
packets to all channels that have a certain HCI socket flag set.
This is especially useful for managment events that are limited to
sockets that have first enabled certain functionality. This allows
for filtering of events without confusing existing users.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Florian Fainelli [Sat, 14 Mar 2015 20:21:59 +0000 (13:21 -0700)]
net: dsa: do not use slave MII bus for fixed PHYs
Commit cd28a1a9baee7 ("net: dsa: fully divert PHY reads/writes if
requested") introduced a check for particular PHYs that need to be
accessed using the slave MII bus created by DSA, but this check was too
inclusive. This would prevent fixed PHYs from being successfully
registered because those should not go through the slave MII bus created
by DSA.
Make sure we check that the PHY is not a fixed PHY to prevent that from
happening.
Fixes: cd28a1a9baee7 ("net: dsa: fully divert PHY reads/writes if requested") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Sat, 14 Mar 2015 19:08:02 +0000 (15:08 -0400)]
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue
Jeff Kirsher says:
====================
Intel Wired LAN Driver Updates 2015-03-13
This series contains updates to ixgbe and ixgbevf.
Don adds additional support for X550 MAC types, which require additional
steps around enabling and disabling Rx. Also cleans up variable type
inconsistency.
I provide a patch to allow relaxed ordering to be enabled on SPARC
architectures. Also cleans up ixgbevf whitespace and code comments to
align the driver with networking coding standard. Lastly cleaned up
uses of memcpy() where ether_addr_copy() could have been used.
Alex removes some dead code in the ixgbe cleanup patch.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Fri, 13 Mar 2015 22:51:10 +0000 (15:51 -0700)]
inet: fill request sock ir_iif for IPv4
Once request socks will be in ehash table, they will need to have
a valid ir_iff field.
This is currently true only for IPv6. This patch extends support
for IPv4 as well.
This means inet_diag_fill_req() can now properly use ir_iif,
which is better for IPv6 link locals anyway, as request sockets
and established sockets will propagate consistent netlink idiag_if.
Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Sat, 14 Mar 2015 18:38:41 +0000 (14:38 -0400)]
Merge branch 'tipc-next'
Jon Maloy says:
====================
tipc: some optimizations and impovements
The commits in this series contain some relatively simple changes that
lead to better throughput across TIPC connections. We also make changes
to the implementation of link transmission queueing and priority
handling, in order to make the code more comprehensible and maintainable.
v2: Commit #2: Redesigned tipc_msg_validate() to use pskb_may_pull(),
as per feedback from David Miller.
Commit #3: Some cosmetic changes to tipc_msg_extract(). I tried to
replace the unconditional skb_linearize() with calls to
pskb_may_pull() at selected locations, but I gave up.
First, skb_trim() requires a fully linearized buffer.
Second, it doesn't make much sense; the whole buffer
will end up linearized, one way or another.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Jon Paul Maloy [Fri, 13 Mar 2015 20:08:11 +0000 (16:08 -0400)]
tipc: clean up handling of message priorities
Messages transferred by TIPC are assigned an "importance priority", -an
integer value indicating how to treat the message when there is link or
destination socket congestion.
There is no separate header field for this value. Instead, the message
user values have been chosen in ascending order according to perceived
importance, so that the message user field can be used for this.
This is not a good solution. First, we have many more users than the
needed priority levels, so we end up with treating more priority
levels than necessary. Second, the user field cannot always
accurately reflect the priority of the message. E.g., a message
fragment packet should really have the priority of the enveloped
user data message, and not the priority of the MSG_FRAGMENTER user.
Until now, we have been working around this problem in different ways,
but it is now time to implement a consistent way of handling such
priorities, although still within the constraint that we cannot
allocate any more bits in the regular data message header for this.
In this commit, we define a new priority level, TIPC_SYSTEM_IMPORTANCE,
that will be the only one used apart from the four (lower) user data
levels. All non-data messages map down to this priority. Furthermore,
we take some free bits from the MSG_FRAGMENTER header and allocate
them to store the priority of the enveloped message. We then adjust
the functions msg_importance()/msg_set_importance() so that they
read/set the correct header fields depending on user type.
This small protocol change is fully compatible, because the code at
the receiving end of a link currently reads the importance level
only from user data messages, where there is no change.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jon Paul Maloy [Fri, 13 Mar 2015 20:08:10 +0000 (16:08 -0400)]
tipc: split link outqueue
struct tipc_link contains one single queue for outgoing packets,
where both transmitted and waiting packets are queued.
This infrastructure is hard to maintain, because we need
to keep a number of fields to keep track of which packets are
sent or unsent, and the number of packets in each category.
A lot of code becomes simpler if we split this queue into a transmission
queue, where sent/unacknowledged packets are kept, and a backlog queue,
where we keep the not yet sent packets.
In this commit we do this separation.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com> Reviewed-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jon Paul Maloy [Fri, 13 Mar 2015 20:08:09 +0000 (16:08 -0400)]
tipc: eliminate unnecessary call to broadcast ack function
The unicast packet header contains a broadcast acknowledge sequence
number, that may need to be conveyed to the broadcast link for proper
treatment. Currently, the function tipc_rcv(), which is on the most
critical data path, calls the function tipc_bclink_acknowledge() to
have this done. This call is made for each received packet, and results
in the unconditional grabbing of the broadcast link spinlock.
This is unnecessary, since we can see directly from tipc_rcv() if
the acknowledged number differs from what has been previously acked
from the node in question. In the vast majority of cases the numbers
won't differ, and there is nothing to update.
We now make the call to tipc_bclink_acknowledge() conditional
to that the two ack values differ.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com> Reviewed-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jon Paul Maloy [Fri, 13 Mar 2015 20:08:08 +0000 (16:08 -0400)]
tipc: extract bundled buffers by cloning instead of copying
When we currently extract a bundled buffer from a message bundle in
the function tipc_msg_extract(), we allocate a new buffer and explicitly
copy the linear data area.
This is unnecessary, since we can just clone the buffer and do
skb_pull() on the clone to move the data pointer to the correct
position.
This is what we do in this commit.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com> Reviewed-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Jon Paul Maloy [Fri, 13 Mar 2015 20:08:07 +0000 (16:08 -0400)]
tipc: eliminate unnecessary linearization of incoming buffers
Currently, TIPC linearizes all incoming buffers directly at reception
before passing them upwards in the stack. This is clearly a waste of
CPU resources, and must be avoided.
In this commit, we eliminate this unnecessary linearization. We still
ensure that at least the message header is linear, and that the buffer
is linearized where this is still needed, i.e. when unbundling and when
reversing messages.
In addition, we ensure that fragmented messages are validated after
reassembly before delivering them upwards in the stack.
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com> Reviewed-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
projects / linux-beck.git / log