- 27 Feb, 2014 17 commits
-
-
Andre Guedes authored
If new scanning parameters are set while background scan is running, we should restart background scanning so these parameters are updated. Signed-off-by:
Andre Guedes <andre.guedes@openbossa.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Andre Guedes authored
This patches creates the public hci_req_add_le_passive_scan helper so it can be re-used outside hci_core.c in the next patch. Signed-off-by:
-
Andre Guedes authored
This patch adds to debugfs the le_auto_conn file. This file will be used to test LE auto connection infrastructure. This file accept writes in the following format: "add <address> <address_type> [auto_connect]" "del <address> <address_type>" "clr" The <address type> values are: * 0 for public address * 1 for random address The [auto_connect] values are (for more details see struct hci_ conn_params): * 0 for disabled (default) * 1 for always * 2 for link loss So for instance, if you want the kernel autonomously establishes connections with device AA:BB:CC:DD:EE:FF (public address) every time the device enters in connectable mode (starts advertising), you should run the command: $ echo "add AA:BB:CC:DD:EE:FF 0 1" > /sys/kernel/debug/bluetooth/hci0/le_auto_conn To delete the connection parameters for that device, run the command: $ echo "del AA:BB:CC:DD:EE:FF 0" > /sys/kernel/debug/bluetooth/hci0/le_auto_conn To clear the connection parameters list, run the command: $ echo "clr" > /sys/kernel/debug/bluetooth/hci0/le_auto_conn Finally. to get the list of connection parameters configured in kernel, read the le_auto_conn file: $ cat /sys/kernel/debug/bluetooth/hci0/le_auto_conn This file is created only if LE is enabled. Signed-off-by:
-
Andre Guedes authored
Only identity addresses are inserted into hdev->pend_le_conns. So, in order to support resolvable private addresses in auto connection mechanism, we should resolve the address before checking for pending connections. Thus, this patch adds an extra check in check_pending_le_conn() and updates 'addr' and 'addr_type' variables before hci_pend_le_conn_ lookup(). Signed-off-by:
-
Andre Guedes authored
We should only accept connection parameters from identity addresses (public or random static). Thus, we should check the address type in hci_conn_params_add(). Additionally, since the IRK is removed during unpair, we should also remove the connection parameters from that device. Signed-off-by:
-
Andre Guedes authored
When hdev is closed (e.g. Mgmt power off command, RFKILL or controller is reset), the ongoing active connections are silently dropped by the controller (no Disconnection Complete Event is sent to host). For that reason, the devices that require HCI_AUTO_CONN_ALWAYS are not added to hdev->pend_le_conns list and they won't auto connect. So to fix this issue, during hdev closing, we remove all pending LE connections. After adapter is powered on, we add a pending LE connection for each HCI_AUTO_CONN_ALWAYS address. This way, the auto connection mechanism works propely after a power off and power on sequence as well as RFKILL block/unblock. Signed-off-by:
-
Andre Guedes authored
If the user sends a mgmt start discovery command while the background scanning is running, we should temporarily stop it. Once the discovery finishes, we start the background scanning again. Signed-off-by:
-
Andre Guedes authored
This patch modifies hci_conn_params_add() and hci_conn_params_del() so they also add/delete pending LE connections according to the auto_ connect option. This way, background scan is automatically triggered/ untriggered when connection parameters are added/removed. For instance, when a new connection parameters with HCI_AUTO_CONN_ALWAYS option is added and we are not connected to the device, we add a pending LE connection for that device. Likewise, when the connection parameters are updated we add or delete a pending LE connection according to its new auto_connect option. Finally, when the connection parameter is deleted we also delete the pending LE connection (if any). Signed-off-by:
-
Andre Guedes authored
This patch introduces the LE auto connection options: HCI_AUTO_CONN_ ALWAYS and HCI_AUTO_CONN_LINK_LOSS. Their working mechanism are described as follows: The HCI_AUTO_CONN_ALWAYS option configures the kernel to always re- establish the connection, no matter the reason the connection was terminated. This feature is required by some LE profiles such as HID over GATT, Health Thermometer and Blood Pressure. These profiles require the host autonomously connect to the device as soon as it enters in connectable mode (start advertising) so the device is able to delivery notifications or indications. The BT_AUTO_CONN_LINK_LOSS option configures the kernel to re- establish the connection in case the connection was terminated due to a link loss. This feature is required by the majority of LE profiles such as Proximity, Find Me, Cycling Speed and Cadence and Time. Signed-off-by:
-
Andre Guedes authored
This patch introduces the LE auto connection infrastructure which will be used to implement the LE auto connection options. In summary, the auto connection mechanism works as follows: Once the first pending LE connection is created, the background scanning is started. When the target device is found in range, the kernel autonomously starts the connection attempt. If connection is established successfully, that pending LE connection is deleted and the background is stopped. To achieve that, this patch introduces the hci_update_background_scan() which controls the background scanning state. This function starts or stops the background scanning based on the hdev->pend_le_conns list. If there is no pending LE connection, the background scanning is stopped. Otherwise, we start the background scanning. Then, every time a pending LE connection is added we call hci_update_ background_scan() so the background scanning is started (in case it is not already running). Likewise, every time a pending LE connection is deleted we call hci_update_background_scan() so the background scanning is stopped (in case this was the last pending LE connection) or it is started again (in case we have more pending LE connections). Finally, we also call hci_update_background_scan() in hci_le_conn_failed() so the background scan is restarted in case the connection establishment fails. This way the background scanning keeps running until all pending LE connection are established. At this point, resolvable addresses are not support by this infrastructure. The proper support is added in upcoming patches. Signed-off-by:
-
Andre Guedes authored
This patch introduces the hdev->pend_le_conn list which holds the device addresses the kernel should autonomously connect. It also introduces some helper functions to manipulate the list. The list and helper functions will be used by the next patch which implements the LE auto connection infrastructure. Signed-off-by:
-
Andre Guedes authored
This patch moves address type conversion (L2CAP address type to HCI address type) to outside hci_connect_le. This way, we avoid back and forth address type conversion in a comming patch. So hci_connect_le() now expects 'dst_type' parameter in HCI address type convention. Signed-off-by:
-
Andre Guedes authored
hci_connect() is a very simple and useless wrapper of hci_connect_acl and hci_connect_le functions. Addtionally, all places where hci_connect is called the link type value is passed explicitly. This way, we can safely delete hci_connect, declare hci_connect_acl and hci_connect_le in hci_core.h and call them directly. No functionality is changed by this patch. Signed-off-by:
-
Andre Guedes authored
This patch removes hci_create_le_conn() since it is not used anymore. Signed-off-by:
-
Andre Guedes authored
Some LE controllers don't support scanning and creating a connection at the same time. So we should always stop scanning in order to establish the connection. Since we may prematurely stop the discovery procedure in favor of the connection establishment, we should also cancel hdev->le_scan_ disable delayed work and set the discovery state to DISCOVERY_STOPPED. This change does a small improvement since it is not mandatory the user stops scanning before connecting anymore. Moreover, this change is required by upcoming LE auto connection mechanism in order to work properly with controllers that don't support background scanning and connection establishment at the same time. In future, we might want to do a small optimization by checking if controller is able to scan and connect at the same time. For now, we want the simplest approach so we always stop scanning (even if the controller is able to carry out both operations). Signed-off-by:
-
Andre Guedes authored
This patch adds the "hci_" prefix to le_conn_failed() helper and declares it in hci_core.h so it can be reused in hci_event.c. Signed-off-by:
-
Andre Guedes authored
This patch moves stop LE scanning duplicate code to one single place and reuses it. This will avoid more duplicate code in upcoming patches. Signed-off-by:
-
- 26 Feb, 2014 3 commits
-
-
Johan Hedberg authored
Now that to-be-received keys are properly tracked we no-longer need the "force" parameter to smp_distribute_keys(). It was essentially acting as an indicator whether all keys have been received, but now it's just redundant together with smp->remote_key_dist. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
-
Johan Hedberg authored
Now that smp->remote_key_dist is tracking the keys we're still waiting for we can use it to simplify the logic for checking whether we're done with key distribution or not. At the same time the reliance on the "force" parameter of smp_distribute_keys goes away and it can completely be removed in a subsequent patch. Signed-off-by:
-
Johan Hedberg authored
To make is easier to track which keys we've received and which ones we're still waiting for simply clear the corresponding key bits from smp->remote_key_dist as they get received. This will allow us to simplify the code for checking for SMP completion in subsequent patches. Signed-off-by:
-
- 25 Feb, 2014 3 commits
-
-
Johan Hedberg authored
The Core Specification (4.1) leaves room for sending an SMP Identity Address Information PDU with an all-zeros BD_ADDR value. This essentially means that we would not have an Identity Address for the device and the only means of identifying it would be the IRK value itself. Due to lack of any known implementations behaving like this it's best to keep our implementation as simple as possible as far as handling such situations is concerned. This patch updates the Identity Address Information handler function to simply ignore the IRK received from such a device. Signed-off-by:
-
Johan Hedberg authored
When the connectable setting is toggled using mgmt_set_connectable the HCI_CONNECTABLE flag will only be set once the related HCI commands succeed. When determining what kind of advertising to do we need to therefore also check whether there is a pending Set Connectable command in addition to the current flag value. The enable_advertising function was already taking care of this for the advertising type with the help of the get_adv_type function, but was failing to do the same for the address type selection. This patch converts the get_adv_type function to be more generic in that it returns the expected connectable state and updates the enable_advertising function to use the return value both for the advertising type as well as the advertising address type. Signed-off-by:
-
Andrzej Kaczmarek authored
When trying to allocate skb for new PDU, l2cap_chan is unlocked so we can sleep waiting for memory as otherwise there's possible deadlock as fixed in e454c844. However, in a6a5568c lock was moved from socket to channel level and it's no longer safe to just unlock and lock again without checking l2cap_chan state since channel can be disconnected when lock is not held. This patch adds missing checks for l2cap_chan state when returning from call which allocates skb. Scenario is easily reproducible by running rfcomm-tester in a loop. BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffa0442169>] l2cap_do_send+0x29/0x120 [bluetooth] PGD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 7 PID: 4038 Comm: krfcommd Not tainted 3.14.0-rc2+ #15 Hardware name: Dell Inc. OptiPlex 790/0HY9JP, BIOS A10 11/24/2011 task: ffff8802bdd731c0 ti: ffff8801ec986000 task.ti: ffff8801ec986000 RIP: 0010:[<ffffffffa0442169>] [<ffffffffa0442169>] l2cap_do_send+0x29/0x120 RSP: 0018:ffff8801ec987ad8 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff8800c5796800 RCX: 0000000000000000 RDX: ffff880410e7a800 RSI: ffff8802b6c1da00 RDI: ffff8800c5796800 RBP: ffff8801ec987af8 R08: 00000000000000c0 R09: 0000000000000300 R10: 000000000000573b R11: 000000000000573a R12: ffff8802b6c1da00 R13: 0000000000000000 R14: ffff8802b6c1da00 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88042dce0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000041257c000 CR4: 00000000000407e0 Stack: ffff8801ec987d78 ffff8800c5796800 ffff8801ec987d78 0000000000000000 ffff8801ec987ba8 ffffffffa0449e37 0000000000000004 ffff8801ec987af0 ffff8801ec987d40 0000000000000282 0000000000000000 ffffffff00000004 Call Trace: [<ffffffffa0449e37>] l2cap_chan_send+0xaa7/0x1120 [bluetooth] [<ffffffff81770100>] ? _raw_spin_unlock_bh+0x20/0x40 [<ffffffffa045188b>] l2cap_sock_sendmsg+0xcb/0x110 [bluetooth] [<ffffffff81652b0f>] sock_sendmsg+0xaf/0xc0 [<ffffffff810a8381>] ? update_curr+0x141/0x200 [<ffffffff810a8961>] ? dequeue_entity+0x181/0x520 [<ffffffff81652b60>] kernel_sendmsg+0x40/0x60 [<ffffffffa04a8505>] rfcomm_send_frame+0x45/0x70 [rfcomm] [<ffffffff810766f0>] ? internal_add_timer+0x20/0x50 [<ffffffffa04a8564>] rfcomm_send_cmd+0x34/0x60 [rfcomm] [<ffffffffa04a8605>] rfcomm_send_disc+0x75/0xa0 [rfcomm] [<ffffffffa04aacec>] rfcomm_run+0x8cc/0x1a30 [rfcomm] [<ffffffffa04aa420>] ? rfcomm_check_accept+0xc0/0xc0 [rfcomm] [<ffffffff8108e3a9>] kthread+0xc9/0xe0 [<ffffffff8108e2e0>] ? flush_kthread_worker+0xb0/0xb0 [<ffffffff817795fc>] ret_from_fork+0x7c/0xb0 [<ffffffff8108e2e0>] ? flush_kthread_worker+0xb0/0xb0 Code: 00 00 66 66 66 66 90 55 48 89 e5 48 83 ec 20 f6 05 d6 a3 02 00 04 RIP [<ffffffffa0442169>] l2cap_do_send+0x29/0x120 [bluetooth] RSP <ffff8801ec987ad8> CR2: 0000000000000000 Signed-off-by:
Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Acked-by:
-
- 24 Feb, 2014 14 commits
-
-
Johan Hedberg authored
To be friendly to user space and to behave well with controllers that lack a proper internal power off procedure we should try to clean up as much state as possible before requesting the HCI driver to power off. This patch updates the power off procedure that's triggered by mgmt_set_powered to clean any scan modes, stop LE scanning and advertising and to disconnect any open connections. The asynchronous cleanup procedure uses the HCI request framework, however since HCI_Disconnect is only covered until its Command Status event we need some extra tracking/waiting of disconnections. This is done by monitoring when hci_conn_count() indicates that there are no more connections. Signed-off-by:
-
Johan Hedberg authored
Once mgmt_set_powered(off) is updated to clear the scan mode we should not just blindly clear the HCI_ADVERTISING flag in mgmt_advertising() but first check if there is a pending set_powered operation. Signed-off-by:
-
Johan Hedberg authored
Once mgmt_set_powered(off) is updated to clear the scan mode we should not just blindly clear the HCI_CONNECTABLE flag in mgmt_connectable() but first check if there is a pending set_powered operation. Signed-off-by:
-
Johan Hedberg authored
Once mgmt_set_powered(off) is updated to clear the scan mode we should not just blindly clear the HCI_DISCOVERABLE flag in mgmt_discoverable() but first check if there is a pending set_powered operation. Signed-off-by:
-
Johan Hedberg authored
Once mgmt_set_powered(off) starts doing disconnections we'll need to care about any disconnections in mgmt.c and not just those with the MGMT_CONNECTED flag set. Therefore, move the check into mgmt.c from hci_event.c. Signed-off-by:
-
Johan Hedberg authored
We'll soon need to make decisions on toggling the HCI_ADVERTISING flag based on pending mgmt_set_powered commands. Therefore, move the handling from hci_event.c into mgmt.c. Signed-off-by:
-
Johan Hedberg authored
This patch adds a convenience function to return the number of connections in the conn_hash list. This will be useful once we update the power off procedure to disconnect any open connections. Signed-off-by:
-
Johan Hedberg authored
The RPA expiry timer is only initialized inside mgmt.c when we receive the first command from user space. This action also involves setting the HCI_MGMT flag for the first time so that flag acts as a good indicator of whether the delayed work variable can be touched or not. This patch fixes hci_dev_do_close to first check the flag. Signed-off-by:
-
Johan Hedberg authored
A user space that supports the Set Privacy command is also expected to be able to handle New IRK events. Therefore, set the HCI_RPA_RESOLVING flag whenever the Set Privacy command is received. Signed-off-by:
-
Marcel Holtmann authored
The identity information in debugfs currently do not include the current in use local RPA. Since the RPA is now stored in the controller information, include it in the debugfs as well. Signed-off-by:
-
Marcel Holtmann authored
The RPA needs to be stored to know which is the current one. Otherwise it is impossible to ensure that always the correct RPA can be programmed into the controller when it is needed. Current code checks if the address in the controller is a RPA, but that can potentially lead to using a RPA that can not be resolved with the IRK that has been distributed. Signed-off-by:
-
Marcel Holtmann authored
When enabling non-connectable advertising, there is no need to advertise with a public address or static address. In case LE privacy has not been enabled a unresolvable private address will be used. Signed-off-by:
-
Marcel Holtmann authored
When running active scanning during LE discovery, do not reveal the own identity to the peer devices. In case LE privacy has been enabled, then a resolvable private address is used. If the LE privacy option is off, then use an unresolvable private address. The public address or static random address is never used in active scanning anymore. This ensures that scan request are send using a random address. Signed-off-by:
-
Marcel Holtmann authored
When using LE Privacy it is useful to know the local identity address, identity address type and identity resolving key. For debugging purposes add these information to debugfs. Signed-off-by:
-
- 23 Feb, 2014 3 commits
-
-
Johan Hedberg authored
Now that the identity address type is always looked up for all successful connections, the hdev->own_addr_type variable has become completely unnecessary. Simply remove it. Signed-off-by:
-
Johan Hedberg authored
This patch ensures that conn->src_type contains the same address type as is used for initiating the connection while the connection attempt is in progress. Once connected this value will be overwritten with the identity address type. Signed-off-by:
-
Johan Hedberg authored
This patch adds support for handling the Set Privacy mgmt command, including copying the value to hdev->irk and toggling the HCI_PRIVACY flag. Signed-off-by:
-
