- 04 Jul, 2014 2 commits
-
-
Johan Hedberg authored
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>
-
Marcel Holtmann authored
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:
-
- 03 Jul, 2014 38 commits
-
-
Johan Hedberg authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
Marcel Holtmann authored
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 authored
This command allows to get the list of currently known controller that are in unconfigured state. Signed-off-by:
-
Marcel Holtmann authored
When a controller in an unconfigured state gets removed, then send Unconfigured Index Removed events. Signed-off-by:
-
Marcel Holtmann authored
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 authored
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:
-
Johan Hedberg authored
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 authored
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 authored
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 authored
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 authored
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 authored
This patch implements the new Load Connection Parameters mgmt command that's intended to load the desired connection parameters for LE devices. Signed-off-by:
-
Johan Hedberg authored
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 authored
The 0x00 action value of mgmt means "scan and report" but do not connect. This is different from HCI_AUTO_CONN_DISABLED so we need a new value for it. Signed-off-by:
-
Johan Hedberg authored
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 authored
We'll soon have specific clear functions for clearing enabled or disabled entries, so rename the function that removes everything to clear_all(). Signed-off-by:
-
Johan Hedberg authored
This patch fixes the following sparse warning caused by a missing declaration in the header file: drivers/bluetooth/btmrvl_main.c:218:5: warning: symbol 'btmrvl_pscan_window_reporting' was not declared. Should it be static? Signed-off-by:
-
Marcel Holtmann authored
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 authored
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 authored
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 authored
For the Intel based USB devices add support for configuration of the public device address. Signed-off-by:
-
Johan Hedberg authored
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 authored
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:
-
Marcel Holtmann authored
For the Broadcom based USB devices add support for configuration of the public device address. Signed-off-by:
-
Marcel Holtmann authored
Some embedded controllers allow the programming of a public address and this adds vendor support for supporting OEM confguration of such addresses. Signed-off-by:
-
Andre Guedes authored
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:
-
Andre Guedes authored
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 authored
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 authored
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:
-
