#
2e7ed5f5 |
|
05-Apr-2024 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_sync: Use advertised PHYs on hci_le_ext_create_conn_sync The extended advertising reports do report the PHYs so this store then in hci_conn so it can be later used in hci_le_ext_create_conn_sync to narrow the PHYs to be scanned since the controller will also perform a scan having a smaller set of PHYs shall reduce the time it takes to find and connect peers. Fixes: 288c90224eec ("Bluetooth: Enable all supported LE PHY by default") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
2615fd9a |
|
16-Feb-2024 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_sync: Fix overwriting request callback In a few cases the stack may generate commands as responses to events which would happen to overwrite the sent_cmd, so this attempts to store the request in req_skb so even if sent_cmd is replaced with a new command the pending request will remain in stored in req_skb. Fixes: 6a98e3836fa2 ("Bluetooth: Add helper for serialized HCI command execution") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
02171da6 |
|
23-Feb-2024 |
Iulia Tanasescu <iulia.tanasescu@nxp.com> |
Bluetooth: ISO: Add hcon for listening bis sk This creates a hcon instance at bis listen, before the PA sync procedure is started. Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
881559af |
|
13-Feb-2024 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_sync: Attempt to dequeue connection attempt If connection is still queued/pending in the cmd_sync queue it means no command has been generated and it should be safe to just dequeue the callback when it is being aborted. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
5f641f03 |
|
09-Feb-2024 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Fix UAF Write in __hci_acl_create_connection_sync This fixes the UAF on __hci_acl_create_connection_sync caused by connection abortion, it uses the same logic as to LE_LINK which uses hci_cmd_sync_cancel to prevent the callback to run if the connection is abort prematurely. Reported-by: syzbot+3f0a39be7a2035700868@syzkaller.appspotmail.com Fixes: 45340097ce6e ("Bluetooth: hci_conn: Only do ACL connections sequentially") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
bf98feea |
|
07-Feb-2024 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Always use sk_timeo as conn_timeout This aligns the use socket sk_timeo as conn_timeout when initiating a connection and then use it when scheduling the resulting HCI command, that way the command is actually aborted synchronously thus not blocking commands generated by hci_abort_conn_sync to inform the controller the connection is to be aborted. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
4aa42119 |
|
05-Feb-2024 |
Jonas Dreßler <verdre@v0yd.nl> |
Bluetooth: Remove pending ACL connection attempts With the last commit we moved to using the hci_sync queue for "Create Connection" requests, removing the need for retrying the paging after finished/failed "Create Connection" requests and after the end of inquiries. hci_conn_check_pending() was used to trigger this retry, we can remove it now. Note that we can also remove the special handling for COMMAND_DISALLOWED errors in the completion handler of "Create Connection", because "Create Connection" requests are now always serialized. This is somewhat reverting commit 4c67bc74f016 ("[Bluetooth] Support concurrent connect requests"). With this, the BT_CONNECT2 state of ACL hci_conn objects should now be back to meaning only one thing: That we received a "Connection Request" from another device (see hci_conn_request_evt), but the response to that is going to be deferred. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
45340097 |
|
05-Feb-2024 |
Jonas Dreßler <verdre@v0yd.nl> |
Bluetooth: hci_conn: Only do ACL connections sequentially Pretty much all bluetooth chipsets only support paging a single device at a time, and if they don't reject a secondary "Create Connection" request while another is still ongoing, they'll most likely serialize those requests in the firware. With commit 4c67bc74f016 ("[Bluetooth] Support concurrent connect requests") we started adding some serialization of our own in case the adapter returns "Command Disallowed" HCI error. This commit was using the BT_CONNECT2 state for the serialization, this state is also used for a few more things (most notably to indicate we're waiting for an inquiry to cancel) and therefore a bit unreliable. Also not all BT firwares would respond with "Command Disallowed" on too many connection requests, some will also respond with "Hardware Failure" (BCM4378), and others will error out later and send a "Connect Complete" event with error "Rejected Limited Resources" (Marvell 88W8897). We can clean things up a bit and also make the serialization more reliable by using our hci_sync machinery to always do "Create Connection" requests in a sequential manner. This is very similar to what we're already doing for establishing LE connections, and it works well there. Note that this causes a test failure in mgmt-tester (test "Pair Device - Power off 1") because the hci_abort_conn_sync() changes the error we return on timeout of the "Create Connection". We'll fix this on the mgmt-tester side by adjusting the expected error for the test. Signed-off-by: Jonas Dreßler <verdre@v0yd.nl> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
e7b02296 |
|
01-Feb-2024 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: Remove BT_HS High Speed, Alternate MAC and PHY (AMP) extension, has been removed from Bluetooth Core specification on 5.3: https://www.bluetooth.com/blog/new-core-specification-v5-3-feature-enhancements/ Fixes: 244bc377591c ("Bluetooth: Add BT_HS config option") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
132d0fd0 |
|
07-Dec-2023 |
Zijun Hu <quic_zijuhu@quicinc.com> |
Bluetooth: hci_conn: Check non NULL function before calling for HFP offload For some controllers such as QCA2066, it does not need to send HCI_Configure_Data_Path to configure non-HCI data transport path to support HFP offload, their device drivers may set hdev->get_codec_config_data as NULL, so Explicitly add this non NULL checking before calling the function. Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
d03376c1 |
|
30-Nov-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: Fix bogus check for re-auth no supported with non-ssp This reverts 19f8def031bfa50c579149b200bfeeb919727b27 "Bluetooth: Fix auth_complete_evt for legacy units" which seems to be working around a bug on a broken controller rather then any limitation imposed by the Bluetooth spec, in fact if there ws not possible to re-auth the command shall fail not succeed. Fixes: 19f8def031bf ("Bluetooth: Fix auth_complete_evt for legacy units") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
fa224d0c |
|
13-Nov-2023 |
Iulia Tanasescu <iulia.tanasescu@nxp.com> |
Bluetooth: ISO: Reassociate a socket with an active BIS For ISO Broadcast, all BISes from a BIG have the same lifespan - they cannot be created or terminated independently from each other. This links together all BIS hcons that are part of the same BIG, so all hcons are kept alive as long as the BIG is active. If multiple BIS sockets are opened for a BIG handle, and only part of them are closed at some point, the associated hcons will be marked as open. If new sockets will later be opened for the same BIG, they will be reassociated with the open BIS hcons. All BIS hcons will be cleaned up and the BIG will be terminated when the last BIS socket is closed from userspace. Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
a85fb91e |
|
17-Oct-2023 |
ZhengHan Wang <wzhmmmmm@gmail.com> |
Bluetooth: Fix double free in hci_conn_cleanup syzbot reports a slab use-after-free in hci_conn_hash_flush [1]. After releasing an object using hci_conn_del_sysfs in the hci_conn_cleanup function, releasing the same object again using the hci_dev_put and hci_conn_put functions causes a double free. Here's a simplified flow: hci_conn_del_sysfs: hci_dev_put put_device kobject_put kref_put kobject_release kobject_cleanup kfree_const kfree(name) hci_dev_put: ... kfree(name) hci_conn_put: put_device ... kfree(name) This patch drop the hci_dev_put and hci_conn_put function call in hci_conn_cleanup function, because the object is freed in hci_conn_del_sysfs function. This patch also fixes the refcounting in hci_conn_add_sysfs() and hci_conn_del_sysfs() to take into account device_add() failures. This fixes CVE-2023-28464. Link: https://syzkaller.appspot.com/bug?id=1bb51491ca5df96a5f724899d1dbb87afda61419 [1] Signed-off-by: ZhengHan Wang <wzhmmmmm@gmail.com> Co-developed-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
181a42ed |
|
11-Oct-2023 |
Ziyang Xuan <william.xuanziyang@huawei.com> |
Bluetooth: Make handle of hci_conn be unique The handle of new hci_conn is always HCI_CONN_HANDLE_MAX + 1 if the handle of the first hci_conn entry in hci_dev->conn_hash->list is not HCI_CONN_HANDLE_MAX + 1. Use ida to manage the allocation of hci_conn->handle to make it be unique. Fixes: 9f78191cc9f1 ("Bluetooth: hci_conn: Always allocate unique handles") Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
fcb89f12 |
|
11-Oct-2023 |
Iulia Tanasescu <iulia.tanasescu@nxp.com> |
Bluetooth: ISO: Fix bcast listener cleanup This fixes the cleanup callback for slave bis and pa sync hcons. Closing all bis hcons will trigger BIG Terminate Sync, while closing all bises and the pa sync hcon will also trigger PA Terminate Sync. Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
71b7bb48 |
|
03-Oct-2023 |
Iulia Tanasescu <iulia.tanasescu@nxp.com> |
Bluetooth: ISO: Match QoS adv handle with BIG handle In case the user binds multiple sockets for the same BIG, the BIG handle should be matched with the associated adv handle, if it has already been allocated previously. Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
31ca583b |
|
03-Oct-2023 |
Iulia Tanasescu <iulia.tanasescu@nxp.com> |
Bluetooth: ISO: Allow binding a bcast listener to 0 bises This makes it possible to bind a broadcast listener to a broadcaster address without asking for any BIS indexes to sync with. Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
1d11d70d |
|
06-Sep-2023 |
Iulia Tanasescu <iulia.tanasescu@nxp.com> |
Bluetooth: ISO: Pass BIG encryption info through QoS This enables a broadcast sink to be informed if the PA it has synced with is associated with an encrypted BIG, by retrieving the socket QoS and checking the encryption field. After PA sync has been successfully established and the first BIGInfo advertising report is received, a new hcon is added and notified to the ISO layer. The ISO layer sets the encryption field of the socket and hcon QoS according to the encryption parameter of the BIGInfo advertising report event. After that, the userspace is woken up, and the QoS of the new PA sync socket can be read, to inspect the encryption field and follow up accordingly. Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
a254b90c |
|
06-Sep-2023 |
Iulia Tanasescu <iulia.tanasescu@nxp.com> |
Bluetooth: ISO: Fix BIS cleanup This fixes the master BIS cleanup procedure - as opposed to CIS cleanup, no HCI disconnect command should be issued. A master BIS should only be terminated by disabling periodic and extended advertising, and terminating the BIG. In case of a Broadcast Receiver, all BIS and PA connections can be cleaned up by calling hci_conn_failed, since it contains all function calls that are necessary for successful cleanup. Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
1ffc6f8c |
|
01-Oct-2023 |
Lee, Chun-Yi <jlee@suse.com> |
Bluetooth: Reject connection with the device which has same BD_ADDR This change is used to relieve CVE-2020-26555. The description of the CVE: Bluetooth legacy BR/EDR PIN code pairing in Bluetooth Core Specification 1.0B through 5.2 may permit an unauthenticated nearby device to spoof the BD_ADDR of the peer device to complete pairing without knowledge of the PIN. [1] The detail of this attack is in IEEE paper: BlueMirror: Reflections on Bluetooth Pairing and Provisioning Protocols [2] It's a reflection attack. The paper mentioned that attacker can induce the attacked target to generate null link key (zero key) without PIN code. In BR/EDR, the key generation is actually handled in the controller which is below HCI. A condition of this attack is that attacker should change the BR_ADDR of his hacking device (Host B) to equal to the BR_ADDR with the target device being attacked (Host A). Thus, we reject the connection with device which has same BD_ADDR both on HCI_Create_Connection and HCI_Connection_Request to prevent the attack. A similar implementation also shows in btstack project. [3][4] Cc: stable@vger.kernel.org Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26555 [1] Link: https://ieeexplore.ieee.org/abstract/document/9474325/authors#authors [2] Link: https://github.com/bluekitchen/btstack/blob/master/src/hci.c#L3523 [3] Link: https://github.com/bluekitchen/btstack/blob/master/src/hci.c#L7297 [4] Signed-off-by: Lee, Chun-Yi <jlee@suse.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
1d8e8014 |
|
06-Sep-2023 |
Ying Hsu <yinghsu@chromium.org> |
Bluetooth: Avoid redundant authentication While executing the Android 13 CTS Verifier Secure Server test on a ChromeOS device, it was observed that the Bluetooth host initiates authentication for an RFCOMM connection after SSP completes. When this happens, some Intel Bluetooth controllers, like AC9560, would disconnect with "Connection Rejected due to Security Reasons (0x0e)". Historically, BlueZ did not mandate this authentication while an authenticated combination key was already in use for the connection. This behavior was changed since commit 7b5a9241b780 ("Bluetooth: Introduce requirements for security level 4"). So, this patch addresses the aforementioned disconnection issue by restoring the previous behavior. Signed-off-by: Ying Hsu <yinghsu@chromium.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
3344d318 |
|
19-Aug-2023 |
Pauli Virtanen <pav@iki.fi> |
Bluetooth: hci_conn: fail SCO/ISO via hci_conn_failed if ACL gone early Not calling hci_(dis)connect_cfm before deleting conn referred to by a socket generally results to use-after-free. When cleaning up SCO connections when the parent ACL is deleted too early, use hci_conn_failed to do the connection cleanup properly. We also need to clean up ISO connections in a similar situation when connecting has started but LE Create CIS is not yet sent, so do it too here. Fixes: ca1fd42e7dbf ("Bluetooth: Fix potential double free caused by hci_conn_unlink") Reported-by: syzbot+cf54c1da6574b6c1b049@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-bluetooth/00000000000013b93805fbbadc50@google.com/ Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
fbdc4bc4 |
|
17-Aug-2023 |
Iulia Tanasescu <iulia.tanasescu@nxp.com> |
Bluetooth: ISO: Use defer setup to separate PA sync and BIG sync This commit implements defer setup support for the Broadcast Sink scenario: By setting defer setup on a broadcast socket before calling listen, the user is able to trigger the PA sync and BIG sync procedures separately. This is useful if the user first wants to synchronize to the periodic advertising transmitted by a Broadcast Source, and trigger the BIG sync procedure later on. If defer setup is set, once a PA sync established event arrives, a new hcon is created and notified to the ISO layer. A child socket associated with the PA sync connection will be added to the accept queue of the listening socket. Once the accept call returns the fd for the PA sync child socket, the user should call read on that fd. This will trigger the BIG create sync procedure, and the PA sync socket will become a listening socket itself. When the BIG sync established event is notified to the ISO layer, the bis connections will be added to the accept queue of the PA sync parent. The user should call accept on the PA sync socket to get the final bis connections. Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
3a15324f |
|
15-Aug-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Fix sending BT_HCI_CMD_LE_CREATE_CONN_CANCEL This fixes sending BT_HCI_CMD_LE_CREATE_CONN_CANCEL when hci_le_create_conn_sync has not been called because HCI_CONN_SCANNING has been clear too early before its cmd_sync callback has been run. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
b5793de3 |
|
05-Aug-2023 |
Pauli Virtanen <pav@iki.fi> |
Bluetooth: hci_conn: avoid checking uninitialized CIG/CIS ids The CIS/CIG ids of ISO connections are defined only when the connection is unicast. Fix the lookup functions to check for unicast first. Ensure CIG/CIS IDs have valid value also in state BT_OPEN. Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
a1f6c3ae |
|
04-Aug-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_sync: Introduce PTR_UINT/UINT_PTR macros This introduces PTR_UINT/UINT_PTR macros and replace the use of PTR_ERR/ERR_PTR. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
a0912892 |
|
04-Aug-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Fix hci_le_set_cig_params When running with concurrent task only one CIS was being assigned so this attempts to rework the way the PDU is constructed so it is handled later at the callback instead of in place. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
f2f84a70 |
|
03-Aug-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Fix not allowing valid CIS ID Only the number of CIS shall be limited to 0x1f, the CIS ID in the other hand is up to 0xef. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
16e3b642 |
|
03-Aug-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Fix modifying handle while aborting This introduces hci_conn_set_handle which takes care of verifying the conditions where the hci_conn handle can be modified, including when hci_conn_abort has been called and also checks that the handles is valid as well. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
69997d50 |
|
26-Jul-2023 |
Pauli Virtanen <pav@iki.fi> |
Bluetooth: ISO: handle bound CIS cleanup via hci_conn Calling hci_conn_del in __iso_sock_close is invalid. It needs hdev->lock, but it cannot be acquired there due to lock ordering. Fix this by doing cleanup via hci_conn_drop. Return hci_conn with refcount 1 from hci_bind_cis and hci_connect_cis, so that the iso_conn always holds one reference. This also fixes refcounting when error handling. Since hci_conn_abort shall handle termination of connections in any state properly, we can handle BT_CONNECT socket state in the same way as BT_CONNECTED. Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
f777d882 |
|
03-Jul-2023 |
Iulia Tanasescu <iulia.tanasescu@nxp.com> |
Bluetooth: ISO: Notify user space about failed bis connections Some use cases require the user to be informed if BIG synchronization fails. This commit makes it so that even if the BIG sync established event arrives with error status, a new hconn is added for each BIS, and the iso layer is notified about the failed connections. Unsuccesful bis connections will be marked using the HCI_CONN_BIG_SYNC_FAILED flag. From the iso layer, the POLLERR event is triggered on the newly allocated bis sockets, before adding them to the accept list of the parent socket. From user space, a new fd for each failed bis connection will be obtained by calling accept. The user should check for the POLLERR event on the new socket, to determine if the connection was successful or not. The HCI_CONN_BIG_SYNC flag has been added to mark whether the BIG sync has been successfully established. This flag is checked at bis cleanup, so the HCI LE BIG Terminate Sync command is only issued if needed. The BT_SK_BIG_SYNC flag indicates if BIG create sync has been called for a listening socket, to avoid issuing the command everytime a BIGInfo advertising report is received. Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
9f78191c |
|
28-Jun-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Always allocate unique handles This attempts to always allocate a unique handle for connections so they can be properly aborted by the likes of hci_abort_conn, so this uses the invalid range as a pool of unset handles that way if userspace is trying to create multiple connections at once each will be given a unique handle which will be considered unset. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
04a51d61 |
|
27-Jun-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_sync: Fix not handling ISO_LINK in hci_abort_conn_sync ISO_LINK connections where not being handled properly on hci_abort_conn_sync which sometimes resulted in sending the wrong commands, or in case of having the reject command being sent by the socket code (iso.c) which is sort of a layer violation. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
a13f316e |
|
26-Jun-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Consolidate code for aborting connections This consolidates code for aborting connections using hci_cmd_sync_queue so it is synchronized with other threads, but because of the fact that some commands may block the cmd_sync_queue while waiting specific events this attempt to cancel those requests by using hci_cmd_sync_cancel. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
6a42e9bf |
|
19-Jun-2023 |
Iulia Tanasescu <iulia.tanasescu@nxp.com> |
Bluetooth: ISO: Support multiple BIGs This adds support for creating multiple BIGs. According to spec, each BIG shall have an unique handle, and each BIG should be associated with a different advertising handle. Otherwise, the LE Create BIG command will fail, with error code Command Disallowed (for reusing a BIG handle), or Unknown Advertising Identifier (for reusing an advertising handle). The btmon snippet below shows an exercise for creating two BIGs for the same controller, by opening two isotest instances with the following command: tools/isotest -i hci0 -s 00:00:00:00:00:00 < HCI Command: LE Create Broadcast Isochronous Group (0x08|0x0068) plen 31 Handle: 0x00 Advertising Handle: 0x01 Number of BIS: 1 SDU Interval: 10000 us (0x002710) Maximum SDU size: 40 Maximum Latency: 10 ms (0x000a) RTN: 0x02 PHY: LE 2M (0x02) Packing: Sequential (0x00) Framing: Unframed (0x00) Encryption: 0x00 Broadcast Code: 00000000000000000000000000000000 > HCI Event: Command Status (0x0f) plen 4 LE Create Broadcast Isochronous Group (0x08|0x0068) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 21 LE Broadcast Isochronous Group Complete (0x1b) Status: Success (0x00) Handle: 0x00 BIG Synchronization Delay: 912 us (0x000390) Transport Latency: 912 us (0x000390) PHY: LE 2M (0x02) NSE: 3 BN: 1 PTO: 1 IRC: 3 Maximum PDU: 40 ISO Interval: 10.00 msec (0x0008) Connection Handle #0: 10 < HCI Command: LE Create Broadcast Isochronous Group (0x08|0x0068) Handle: 0x01 Advertising Handle: 0x02 Number of BIS: 1 SDU Interval: 10000 us (0x002710) Maximum SDU size: 40 Maximum Latency: 10 ms (0x000a) RTN: 0x02 PHY: LE 2M (0x02) Packing: Sequential (0x00) Framing: Unframed (0x00) Encryption: 0x00 Broadcast Code: 00000000000000000000000000000000 > HCI Event: Command Status (0x0f) plen 4 LE Create Broadcast Isochronous Group (0x08|0x0068) ncmd 1 Status: Success (0x00) Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
7f74563e |
|
01-Jun-2023 |
Pauli Virtanen <pav@iki.fi> |
Bluetooth: ISO: do not emit new LE Create CIS if previous is pending LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 #129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 #130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 #131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 #132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 #133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 #134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 #135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 #136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80be6ffc ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
a0bfde16 |
|
30-May-2023 |
Iulia Tanasescu <iulia.tanasescu@nxp.com> |
Bluetooth: ISO: Add support for connecting multiple BISes It is required for some configurations to have multiple BISes as part of the same BIG. Similar to the flow implemented for unicast, DEFER_SETUP will also be used to bind multiple BISes for the same BIG, before starting Periodic Advertising and creating the BIG. The user will have to open a new socket for each BIS. By setting the BT_DEFER_SETUP socket option and calling connect, a new connection will be added for the BIG and advertising handle set by the socket QoS parameters. Since all BISes will be bound for the same BIG and advertising handle, the socket QoS options and base parameters should match for all connections. By calling connect on a socket that does not have the BT_DEFER_SETUP option set, periodic advertising will be started and the BIG will be created, with a BIS for each previously bound connection. Since a BIG cannot be reconfigured with additional BISes after creation, no more connections can be bound for the BIG after the start periodic advertising and create BIG commands have been queued. The bis_cleanup function has also been updated, so that the advertising set and the BIG will not be terminated unless there are no more bound or connected BISes. The HCI_CONN_BIG_CREATED connection flag has been added to indicate that the BIG has been successfully created. This flag is checked at bis_cleanup, so that the BIG is only terminated if the HCI_LE_Create_BIG_Complete has been received. This implementation has been tested on hardware, using the "isotest" tool with an additional command line option, to specify the number of BISes to create as part of the desired BIG: tools/isotest -i hci0 -s 00:00:00:00:00:00 -N 2 -G 1 -T 1 The btmon log shows that a BIG containing 2 BISes has been created: < HCI Command: LE Create Broadcast Isochronous Group (0x08|0x0068) plen 31 Handle: 0x01 Advertising Handle: 0x01 Number of BIS: 2 SDU Interval: 10000 us (0x002710) Maximum SDU size: 40 Maximum Latency: 10 ms (0x000a) RTN: 0x02 PHY: LE 2M (0x02) Packing: Sequential (0x00) Framing: Unframed (0x00) Encryption: 0x00 Broadcast Code: 00000000000000000000000000000000 > HCI Event: Command Status (0x0f) plen 4 LE Create Broadcast Isochronous Group (0x08|0x0068) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 23 LE Broadcast Isochronous Group Complete (0x1b) Status: Success (0x00) Handle: 0x01 BIG Synchronization Delay: 1974 us (0x0007b6) Transport Latency: 1974 us (0x0007b6) PHY: LE 2M (0x02) NSE: 3 BN: 1 PTO: 1 IRC: 3 Maximum PDU: 40 ISO Interval: 10.00 msec (0x0008) Connection Handle #0: 10 Connection Handle #1: 11 < HCI Command: LE Setup Isochronous Data Path (0x08|0x006e) plen 13 Handle: 10 Data Path Direction: Input (Host to Controller) (0x00) Data Path: HCI (0x00) Coding Format: Transparent (0x03) Company Codec ID: Ericsson Technology Licensing (0) Vendor Codec ID: 0 Controller Delay: 0 us (0x000000) Codec Configuration Length: 0 Codec Configuration: > HCI Event: Command Complete (0x0e) plen 6 LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 Status: Success (0x00) Handle: 10 < HCI Command: LE Setup Isochronous Data Path (0x08|0x006e) plen 13 Handle: 11 Data Path Direction: Input (Host to Controller) (0x00) Data Path: HCI (0x00) Coding Format: Transparent (0x03) Company Codec ID: Ericsson Technology Licensing (0) Vendor Codec ID: 0 Controller Delay: 0 us (0x000000) Codec Configuration Length: 0 Codec Configuration: > HCI Event: Command Complete (0x0e) plen 6 LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 Status: Success (0x00) Handle: 11 < ISO Data TX: Handle 10 flags 0x02 dlen 44 < ISO Data TX: Handle 11 flags 0x02 dlen 44 > HCI Event: Number of Completed Packets (0x13) plen 5 Num handles: 1 Handle: 10 Count: 1 > HCI Event: Number of Completed Packets (0x13) plen 5 Num handles: 1 Handle: 11 Count: 1 Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
b4066eb0 |
|
11-Jul-2023 |
Siddh Raman Pant <code@siddh.me> |
Bluetooth: hci_conn: return ERR_PTR instead of NULL when there is no link hci_connect_sco currently returns NULL when there is no link (i.e. when hci_conn_link() returns NULL). sco_connect() expects an ERR_PTR in case of any error (see line 266 in sco.c). Thus, hcon set as NULL passes through to sco_conn_add(), which tries to get hcon->hdev, resulting in dereferencing a NULL pointer as reported by syzkaller. The same issue exists for iso_connect_cis() calling hci_connect_cis(). Thus, make hci_connect_sco() and hci_connect_cis() return ERR_PTR instead of NULL. Reported-and-tested-by: syzbot+37acd5d80d00d609d233@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=37acd5d80d00d609d233 Fixes: 06149746e720 ("Bluetooth: hci_conn: Add support for linking multiple hcon") Signed-off-by: Siddh Raman Pant <code@siddh.me> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
195ef75e |
|
18-Jun-2023 |
Pauli Virtanen <pav@iki.fi> |
Bluetooth: use RCU for hci_conn_params and iterate safely in hci_sync hci_update_accept_list_sync iterates over hdev->pend_le_conns and hdev->pend_le_reports, and waits for controller events in the loop body, without holding hdev lock. Meanwhile, these lists and the items may be modified e.g. by le_scan_cleanup. This can invalidate the list cursor or any other item in the list, resulting to invalid behavior (eg use-after-free). Use RCU for the hci_conn_params action lists. Since the loop bodies in hci_sync block and we cannot use RCU or hdev->lock for the whole loop, copy list items first and then iterate on the copy. Only the flags field is written from elsewhere, so READ_ONCE/WRITE_ONCE should guarantee we read valid values. Free params everywhere with hci_conn_params_free so the cleanup is guaranteed to be done properly. This fixes the following, which can be triggered e.g. by BlueZ new mgmt-tester case "Add + Remove Device Nowait - Success", or by changing hci_le_set_cig_params to always return false, and running iso-tester: ================================================================== BUG: KASAN: slab-use-after-free in hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841) Read of size 8 at addr ffff888001265018 by task kworker/u3:0/32 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl (./arch/x86/include/asm/irqflags.h:134 lib/dump_stack.c:107) print_report (mm/kasan/report.c:320 mm/kasan/report.c:430) ? __virt_addr_valid (./include/linux/mmzone.h:1915 ./include/linux/mmzone.h:2011 arch/x86/mm/physaddr.c:65) ? hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841) kasan_report (mm/kasan/report.c:538) ? hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841) hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2536 net/bluetooth/hci_sync.c:2723 net/bluetooth/hci_sync.c:2841) ? __pfx_hci_update_passive_scan_sync (net/bluetooth/hci_sync.c:2780) ? mutex_lock (kernel/locking/mutex.c:282) ? __pfx_mutex_lock (kernel/locking/mutex.c:282) ? __pfx_mutex_unlock (kernel/locking/mutex.c:538) ? __pfx_update_passive_scan_sync (net/bluetooth/hci_sync.c:2861) hci_cmd_sync_work (net/bluetooth/hci_sync.c:306) process_one_work (./arch/x86/include/asm/preempt.h:27 kernel/workqueue.c:2399) worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2538) ? __pfx_worker_thread (kernel/workqueue.c:2480) kthread (kernel/kthread.c:376) ? __pfx_kthread (kernel/kthread.c:331) ret_from_fork (arch/x86/entry/entry_64.S:314) </TASK> Allocated by task 31: kasan_save_stack (mm/kasan/common.c:46) kasan_set_track (mm/kasan/common.c:52) __kasan_kmalloc (mm/kasan/common.c:374 mm/kasan/common.c:383) hci_conn_params_add (./include/linux/slab.h:580 ./include/linux/slab.h:720 net/bluetooth/hci_core.c:2277) hci_connect_le_scan (net/bluetooth/hci_conn.c:1419 net/bluetooth/hci_conn.c:1589) hci_connect_cis (net/bluetooth/hci_conn.c:2266) iso_connect_cis (net/bluetooth/iso.c:390) iso_sock_connect (net/bluetooth/iso.c:899) __sys_connect (net/socket.c:2003 net/socket.c:2020) __x64_sys_connect (net/socket.c:2027) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) Freed by task 15: kasan_save_stack (mm/kasan/common.c:46) kasan_set_track (mm/kasan/common.c:52) kasan_save_free_info (mm/kasan/generic.c:523) __kasan_slab_free (mm/kasan/common.c:238 mm/kasan/common.c:200 mm/kasan/common.c:244) __kmem_cache_free (mm/slub.c:1807 mm/slub.c:3787 mm/slub.c:3800) hci_conn_params_del (net/bluetooth/hci_core.c:2323) le_scan_cleanup (net/bluetooth/hci_conn.c:202) process_one_work (./arch/x86/include/asm/preempt.h:27 kernel/workqueue.c:2399) worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2538) kthread (kernel/kthread.c:376) ret_from_fork (arch/x86/entry/entry_64.S:314) ================================================================== Fixes: e8907f76544f ("Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 3") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
5b6d345d |
|
25-Jun-2023 |
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> |
Bluetooth: hci_conn: Use kmemdup() to replace kzalloc + memcpy Use kmemdup rather than duplicating its implementation. ./net/bluetooth/hci_conn.c:1880:7-14: WARNING opportunity for kmemdup. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5597 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
14f0dcec |
|
08-Jun-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: ISO: Rework sync_interval to be sync_factor This rework sync_interval to be sync_factor as having sync_interval in the order of seconds is sometimes not disarable. Wit sync_factor the application can tell how many SDU intervals it wants to send an announcement with PA, the EA interval is set to 2 times that so a factor of 24 of BIG SDU interval of 10ms would look like the following: < HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen 25 Handle: 0x01 Properties: 0x0000 Min advertising interval: 480.000 msec (0x0300) Max advertising interval: 480.000 msec (0x0300) Channel map: 37, 38, 39 (0x07) Own address type: Random (0x01) Peer address type: Public (0x00) Peer address: 00:00:00:00:00:00 (OUI 00-00-00) Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00) TX power: Host has no preference (0x7f) Primary PHY: LE 1M (0x01) Secondary max skip: 0x00 Secondary PHY: LE 2M (0x02) SID: 0x00 Scan request notifications: Disabled (0x00) < HCI Command: LE Set Periodic Advertising Parameters (0x08|0x003e) plen 7 Handle: 1 Min interval: 240.00 msec (0x00c0) Max interval: 240.00 msec (0x00c0) Properties: 0x0000 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
6b9545dc |
|
01-Jun-2023 |
Pauli Virtanen <pav@iki.fi> |
Bluetooth: ISO: use hci_sync for setting CIG parameters When reconfiguring CIG after disconnection of the last CIS, LE Remove CIG shall be sent before LE Set CIG Parameters. Otherwise, it fails because CIG is in the inactive state and not configurable (Core v5.3 Vol 6 Part B Sec. 4.5.14.3). This ordering is currently wrong under suitable timing conditions, because LE Remove CIG is sent via the hci_sync queue and may be delayed, but Set CIG Parameters is via hci_send_cmd. Make the ordering well-defined by sending also Set CIG Parameters via hci_sync. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
6c242c64 |
|
01-Jun-2023 |
Pauli Virtanen <pav@iki.fi> |
Bluetooth: ISO: don't try to remove CIG if there are bound CIS left Consider existing BOUND & CONNECT state CIS to block CIG removal. Otherwise, under suitable timing conditions we may attempt to remove CIG while Create CIS is pending, which fails. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
e6a7a46b |
|
21-May-2023 |
Pauli Virtanen <pav@iki.fi> |
Bluetooth: ISO: Fix CIG auto-allocation to select configurable CIG Make CIG auto-allocation to select the first CIG_ID that is still configurable. Also use correct CIG_ID range (see Core v5.3 Vol 4 Part E Sec 7.8.97 p.2553). Previously, it would always select CIG_ID 0 regardless of anything, because cis_list with data.cis == 0xff (BT_ISO_QOS_CIS_UNSET) would not count any CIS. Since we are not adding CIS here, use find_cis instead. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
31c5f916 |
|
21-May-2023 |
Pauli Virtanen <pav@iki.fi> |
Bluetooth: ISO: consider right CIS when removing CIG at cleanup When looking for CIS blocking CIG removal, consider only the CIS with the right CIG ID. Don't try to remove CIG with unset CIG ID. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
a2904d28 |
|
03-May-2023 |
Ruihan Li <lrh2000@pku.edu.cn> |
Bluetooth: Unlink CISes when LE disconnects in hci_conn_del Currently, hci_conn_del calls hci_conn_unlink for BR/EDR, (e)SCO, and CIS connections, i.e., everything except LE connections. However, if (e)SCO connections are unlinked when BR/EDR disconnects, CIS connections should also be unlinked when LE disconnects. In terms of disconnection behavior, CIS and (e)SCO connections are not too different. One peculiarity of CIS is that when CIS connections are disconnected, the CIS handle isn't deleted, as per [BLUETOOTH CORE SPECIFICATION Version 5.4 | Vol 4, Part E] 7.1.6 Disconnect command: All SCO, eSCO, and CIS connections on a physical link should be disconnected before the ACL connection on the same physical connection is disconnected. If it does not, they will be implicitly disconnected as part of the ACL disconnection. ... Note: As specified in Section 7.7.5, on the Central, the handle for a CIS remains valid even after disconnection and, therefore, the Host can recreate a disconnected CIS at a later point in time using the same connection handle. Since hci_conn_link invokes both hci_conn_get and hci_conn_hold, hci_conn_unlink should perform both hci_conn_put and hci_conn_drop as well. However, currently it performs only hci_conn_put. This patch makes hci_conn_unlink call hci_conn_drop as well, which simplifies the logic in hci_conn_del a bit and may benefit future users of hci_conn_unlink. But it is noted that this change additionally implies that hci_conn_unlink can queue disc_work on conn itself, with the following call stack: hci_conn_unlink(conn) [conn->parent == NULL] -> hci_conn_unlink(child) [child->parent == conn] -> hci_conn_drop(child->parent) -> queue_delayed_work(&conn->disc_work) Queued disc_work after hci_conn_del can be spurious, so during the process of hci_conn_del, it is necessary to make the call to cancel_delayed_work(&conn->disc_work) after invoking hci_conn_unlink. Signed-off-by: Ruihan Li <lrh2000@pku.edu.cn> Co-developed-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
a2ac591c |
|
03-May-2023 |
Ruihan Li <lrh2000@pku.edu.cn> |
Bluetooth: Fix UAF in hci_conn_hash_flush again Commit 06149746e720 ("Bluetooth: hci_conn: Add support for linking multiple hcon") reintroduced a previously fixed bug [1] ("KASAN: slab-use-after-free Read in hci_conn_hash_flush"). This bug was originally fixed by commit 5dc7d23e167e ("Bluetooth: hci_conn: Fix possible UAF"). The hci_conn_unlink function was added to avoid invalidating the link traversal caused by successive hci_conn_del operations releasing extra connections. However, currently hci_conn_unlink itself also releases extra connections, resulted in the reintroduced bug. This patch follows a more robust solution for cleaning up all connections, by repeatedly removing the first connection until there are none left. This approach does not rely on the inner workings of hci_conn_del and ensures proper cleanup of all connections. Meanwhile, we need to make sure that hci_conn_del never fails. Indeed it doesn't, as it now always returns zero. To make this a bit clearer, this patch also changes its return type to void. Reported-by: syzbot+8bb72f86fc823817bc5d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-bluetooth/000000000000aa920505f60d25ad@google.com/ Fixes: 06149746e720 ("Bluetooth: hci_conn: Add support for linking multiple hcon") Signed-off-by: Ruihan Li <lrh2000@pku.edu.cn> Co-developed-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
2910431a |
|
03-May-2023 |
Ruihan Li <lrh2000@pku.edu.cn> |
Bluetooth: Refcnt drop must be placed last in hci_conn_unlink If hci_conn_put(conn->parent) reduces conn->parent's reference count to zero, it can immediately deallocate conn->parent. At the same time, conn->link->list has its head in conn->parent, causing use-after-free problems in the latter list_del_rcu(&conn->link->list). This problem can be easily solved by reordering the two operations, i.e., first performing the list removal with list_del_rcu and then decreasing the refcnt with hci_conn_put. Reported-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Closes: https://lore.kernel.org/linux-bluetooth/CABBYNZ+1kce8_RJrLNOXd_8=Mdpb=2bx4Nto-hFORk=qiOkoCg@mail.gmail.com/ Fixes: 06149746e720 ("Bluetooth: hci_conn: Add support for linking multiple hcon") Signed-off-by: Ruihan Li <lrh2000@pku.edu.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
ca1fd42e |
|
03-May-2023 |
Ruihan Li <lrh2000@pku.edu.cn> |
Bluetooth: Fix potential double free caused by hci_conn_unlink The hci_conn_unlink function is being called by hci_conn_del, which means it should not call hci_conn_del with the input parameter conn again. If it does, conn may have already been released when hci_conn_unlink returns, leading to potential UAF and double-free issues. This patch resolves the problem by modifying hci_conn_unlink to release only conn's child links when necessary, but never release conn itself. Reported-by: syzbot+690b90b14f14f43f4688@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-bluetooth/000000000000484a8205faafe216@google.com/ Fixes: 06149746e720 ("Bluetooth: hci_conn: Add support for linking multiple hcon") Signed-off-by: Ruihan Li <lrh2000@pku.edu.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Reported-by: syzbot+690b90b14f14f43f4688@syzkaller.appspotmail.com Reported-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Reported-by: syzbot+8bb72f86fc823817bc5d@syzkaller.appspotmail.com
|
#
c09b80be |
|
12-Apr-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED When submitting HCI_OP_LE_CREATE_CIS the code shall wait for HCI_EVT_LE_CIS_ESTABLISHED thus enforcing the serialization of HCI_OP_LE_CREATE_CIS as the Core spec does not allow to send them in parallel: BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 4, Part E page 2566: If the Host issues this command before all the HCI_LE_CIS_Established events from the previous use of the command have been generated, the Controller shall return the error code Command Disallowed (0x0C). Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
c14516fa |
|
11-Apr-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Fix not matching by CIS ID This fixes only matching CIS by address which prevents creating new hcon if upper layer is requesting a specific CIS ID. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
06149746 |
|
11-Apr-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Add support for linking multiple hcon Since it is required for some configurations to have multiple CIS with the same peer which is now covered by iso-tester in the following test cases: ISO AC 6(i) - Success ISO AC 7(i) - Success ISO AC 8(i) - Success ISO AC 9(i) - Success ISO AC 11(i) - Success Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
9e3c2ea6 |
|
11-Apr-2023 |
Iulia Tanasescu <iulia.tanasescu@nxp.com> |
Bluetooth: hci_conn: remove extra line in hci_le_big_create_sync Remove extra line setting the broadcast code parameter of the hci_cp_le_create_big struct to 0. The broadcast code is copied from the QoS struct. Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
0fe8c8d0 |
|
31-Mar-2023 |
Iulia Tanasescu <iulia.tanasescu@nxp.com> |
Bluetooth: Split bt_iso_qos into dedicated structures Split bt_iso_qos into dedicated unicast and broadcast structures and add additional broadcast parameters. Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections") Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
5dc7d23e |
|
03-Apr-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Fix possible UAF This fixes the following trace: ================================================================== BUG: KASAN: slab-use-after-free in hci_conn_del+0xba/0x3a0 Write of size 8 at addr ffff88800208e9c8 by task iso-tester/31 CPU: 0 PID: 31 Comm: iso-tester Not tainted 6.3.0-rc2-g991aa4a69a47 #4716 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc36 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x1d/0x70 print_report+0xce/0x610 ? __virt_addr_valid+0xd4/0x150 ? hci_conn_del+0xba/0x3a0 kasan_report+0xdd/0x110 ? hci_conn_del+0xba/0x3a0 hci_conn_del+0xba/0x3a0 hci_conn_hash_flush+0xf2/0x120 hci_dev_close_sync+0x388/0x920 hci_unregister_dev+0x122/0x260 vhci_release+0x4f/0x90 __fput+0x102/0x430 task_work_run+0xf1/0x160 ? __pfx_task_work_run+0x10/0x10 ? mark_held_locks+0x24/0x90 exit_to_user_mode_prepare+0x170/0x180 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x4e/0x90 entry_SYSCALL_64_after_hwframe+0x70/0xda Fixes: 0f00cd322d22 ("Bluetooth: Free potentially unfreed SCO connection") Link: https://syzkaller.appspot.com/bug?extid=8bb72f86fc823817bc5d Cc: <stable@vger.kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
b62e7220 |
|
24-Mar-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: Fix printing errors if LE Connection times out This fixes errors like bellow when LE Connection times out since that is actually not a controller error: Bluetooth: hci0: Opcode 0x200d failed: -110 Bluetooth: hci0: request failed to create LE connection: err -110 Instead the code shall properly detect if -ETIMEDOUT is returned and send HCI_OP_LE_CREATE_CONN_CANCEL to give up on the connection. Link: https://github.com/bluez/bluez/issues/340 Fixes: 8e8b92ee60de ("Bluetooth: hci_sync: Add hci_le_create_conn_sync") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
19cf60bf |
|
24-Mar-2023 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Fix not cleaning up on LE Connection failure hci_connect_le_scan_cleanup shall always be invoked to cleanup the states and re-enable passive scanning if necessary, otherwise it may cause the pending action to stay active causing multiple attempts to connect. Fixes: 9b3628d79b46 ("Bluetooth: hci_sync: Cleanup hci_conn if it cannot be aborted") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
5cd39700 |
|
03-Feb-2023 |
Archie Pusaka <apusaka@chromium.org> |
Bluetooth: Make sure LE create conn cancel is sent when timeout When sending LE create conn command, we set a timer with a duration of HCI_LE_CONN_TIMEOUT before timing out and calling create_le_conn_complete. Additionally, when receiving the command complete, we also set a timer with the same duration to call le_conn_timeout. Usually the latter will be triggered first, which then sends a LE create conn cancel command. However, due to the nature of racing, it is possible for the former to be called first, thereby calling the chain hci_conn_failed -> hci_conn_del -> cancel_delayed_work, thereby preventing LE create conn cancel to be sent. In this situation, the controller will be stuck in trying the LE connection. This patch flushes le_conn_timeout on create_le_conn_complete to make sure we always send LE create connection cancel, if necessary. Signed-off-by: Archie Pusaka <apusaka@chromium.org> Reviewed-by: Ying Hsu <yinghsu@chromium.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
0f00cd32 |
|
03-Feb-2023 |
Archie Pusaka <apusaka@chromium.org> |
Bluetooth: Free potentially unfreed SCO connection It is possible to initiate a SCO connection while deleting the corresponding ACL connection, e.g. in below scenario: (1) < hci setup sync connect command (2) > hci disconn complete event (for the acl connection) (3) > hci command complete event (for(1), failure) When it happens, hci_cs_setup_sync_conn won't be able to obtain the reference to the SCO connection, so it will be stuck and potentially hinder subsequent connections to the same device. This patch prevents that by also deleting the SCO connection if it is still not established when the corresponding ACL connection is deleted. Signed-off-by: Archie Pusaka <apusaka@chromium.org> Reviewed-by: Ying Hsu <yinghsu@chromium.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
a00a29b0 |
|
27-Jan-2023 |
Kees Cook <keescook@chromium.org> |
Bluetooth: hci_conn: Refactor hci_bind_bis() since it always succeeds The compiler thinks "conn" might be NULL after a call to hci_bind_bis(), which cannot happen. Avoid any confusion by just making it not return a value since it cannot fail. Fixes the warnings seen with GCC 13: In function 'arch_atomic_dec_and_test', inlined from 'atomic_dec_and_test' at ../include/linux/atomic/atomic-instrumented.h:576:9, inlined from 'hci_conn_drop' at ../include/net/bluetooth/hci_core.h:1391:6, inlined from 'hci_connect_bis' at ../net/bluetooth/hci_conn.c:2124:3: ../arch/x86/include/asm/rmwcc.h:37:9: warning: array subscript 0 is outside array bounds of 'atomic_t[0]' [-Warray-bounds=] 37 | asm volatile (fullop CC_SET(cc) \ | ^~~ ... In function 'hci_connect_bis': cc1: note: source object is likely at address zero Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections") Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: linux-bluetooth@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
3aa21311 |
|
03-Jan-2023 |
Zhengchao Shao <shaozhengchao@huawei.com> |
Bluetooth: hci_conn: Fix memory leaks When hci_cmd_sync_queue() failed in hci_le_terminate_big() or hci_le_big_terminate(), the memory pointed by variable d is not freed, which will cause memory leak. Add release process to error path. Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections") Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
50757a25 |
|
05-Dec-2022 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Fix crash on hci_create_cis_sync When attempting to connect multiple ISO sockets without using DEFER_SETUP may result in the following crash: BUG: KASAN: null-ptr-deref in hci_create_cis_sync+0x18b/0x2b0 Read of size 2 at addr 0000000000000036 by task kworker/u3:1/50 CPU: 0 PID: 50 Comm: kworker/u3:1 Not tainted 6.0.0-rc7-02243-gb84a13ff4eda #4373 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-1.fc36 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl+0x19/0x27 kasan_report+0xbc/0xf0 ? hci_create_cis_sync+0x18b/0x2b0 hci_create_cis_sync+0x18b/0x2b0 ? get_link_mode+0xd0/0xd0 ? __ww_mutex_lock_slowpath+0x10/0x10 ? mutex_lock+0xe0/0xe0 ? get_link_mode+0xd0/0xd0 hci_cmd_sync_work+0x111/0x190 process_one_work+0x427/0x650 worker_thread+0x87/0x750 ? process_one_work+0x650/0x650 kthread+0x14e/0x180 ? kthread_exit+0x50/0x50 ret_from_fork+0x22/0x30 </TASK> Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
3958e877 |
|
30-Oct-2022 |
Kang Minchul <tegongkang@gmail.com> |
Bluetooth: Use kzalloc instead of kmalloc/memset Replace kmalloc+memset by kzalloc for better readability and simplicity. This addresses the cocci warning below: WARNING: kzalloc should be used for d, instead of kmalloc/memset Signed-off-by: Kang Minchul <tegongkang@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
37224a29 |
|
16-Oct-2022 |
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> |
Bluetooth: Use kzalloc instead of kmalloc/memset Use kzalloc rather than duplicating its implementation, which makes code simple and easy to understand. ./net/bluetooth/hci_conn.c:2038:6-13: WARNING: kzalloc should be used for cp, instead of kmalloc/memset. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2406 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
d11ab690 |
|
11-Oct-2022 |
Pauli Virtanen <pav@iki.fi> |
Bluetooth: hci_conn: use HCI dst_type values also for BIS For ISO BIS related functions in hci_conn.c, make dst_type values be HCI address type values, not ISO socket address type values. This makes it consistent with CIS functions. Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
5638d9ea |
|
17-Oct-2022 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Fix not restoring ISO buffer count on disconnect When disconnecting an ISO link the controller may not generate HCI_EV_NUM_COMP_PKTS for unacked packets which needs to be restored in hci_conn_del otherwise the host would assume they are still in use and would not be able to use all the buffers available. Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Tested-by: Frédéric Danis <frederic.danis@collabora.com>
|
#
b36a234d |
|
11-Oct-2022 |
Pauli Virtanen <pav@iki.fi> |
Bluetooth: hci_conn: Fix CIS connection dst_type handling hci_connect_cis and iso_connect_cis call hci_bind_cis inconsistently with dst_type being either ISO socket address type or the HCI type, but these values cannot be mixed like this. Fix this by using only the HCI type. CIS connection dst_type was also not initialized in hci_bind_cis, even though it is used in hci_conn_hash_lookup_cis to find existing connections. Set the value in hci_bind_cis, so that existing CIS connections are found e.g. when doing deferred socket connections, also when dst_type is not 0 (ADDR_LE_DEV_PUBLIC). Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
1a942de0 |
|
16-Aug-2022 |
Brian Gix <brian.gix@intel.com> |
Bluetooth: Move hci_abort_conn to hci_conn.c hci_abort_conn() is a wrapper around a number of DISCONNECT and CREATE_CONN_CANCEL commands that was being invoked from hci_request request queues, which are now deprecated. There are two versions: hci_abort_conn() which can be invoked from the hci_event thread, and hci_abort_conn_sync() which can be invoked within a hci_sync cmd chain. Signed-off-by: Brian Gix <brian.gix@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
e07a06b4 |
|
05-Aug-2022 |
Brian Gix <brian.gix@intel.com> |
Bluetooth: Convert SCO configure_datapath to hci_sync Recoding HCI cmds to offload SCO codec to use hci_sync mechanism rather than deprecated hci_request mechanism. Signed-off-by: Brian Gix <brian.gix@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
10b9adb5 |
|
28-Jul-2022 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Fix updating ISO QoS PHY BT_ISO_QOS has different semantics when it comes to QoS PHY as it uses 0x00 to disable a direction but that value is invalid over HCI and sockets using DEFER_SETUP to connect may attempt to use hci_bind_cis multiple times in order to detect if the parameters have changed, so to fix the code will now just mirror the PHY for the parameters of HCI_OP_LE_SET_CIG_PARAMS and will not update the PHY of the socket leaving it disabled. Fixes: 26afbd826ee32 ("Bluetooth: Add initial implementation of CIS connections") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
eca0ae4a |
|
09-Mar-2022 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: Add initial implementation of BIS connections This adds initial support for BIS/BIG which includes: == Broadcaster role: Setup a periodic advertising and create a BIG == > tools/isotest -s 00:00:00:00:00:00 isotest[63]: Connected [00:00:00:00:00:00] isotest[63]: QoS BIG 0x00 BIS 0x00 Packing 0x00 Framing 0x00] isotest[63]: Output QoS [Interval 10000 us Latency 10 ms SDU 40 PHY 0x02 RTN 2] isotest[63]: Sending ... isotest[63]: Number of packets: 1 isotest[63]: Socket jitter buffer: 80 buffer < HCI Command: LE Set Perio.. (0x08|0x003e) plen 7 ... > HCI Event: Command Complete (0x0e) plen 4 LE Set Periodic Advertising Parameters (0x08|0x003e) ncmd 1 Status: Success (0x00) < HCI Command: LE Set Perio.. (0x08|0x003f) plen 7 ... > HCI Event: Command Complete (0x0e) plen 4 LE Set Periodic Advertising Data (0x08|0x003f) ncmd 1 Status: Success (0x00) < HCI Command: LE Set Perio.. (0x08|0x0040) plen 2 ... > HCI Event: Command Complete (0x0e) plen 4 LE Set Periodic Advertising Enable (0x08|0x0040) ncmd 1 Status: Success (0x00) < HCI Command: LE Create B.. (0x08|0x0068) plen 31 ... > HCI Event: Command Status (0x0f) plen 4 LE Create Broadcast Isochronous Group (0x08|0x0068) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 21 LE Broadcast Isochronous Group Complete (0x1b) ... == Broadcast Receiver role: Create a PA Sync and BIG Sync == > tools/isotest -i hci1 -d 00:AA:01:00:00:00 isotest[66]: Waiting for connection 00:AA:01:00:00:00... < HCI Command: LE Periodic Advert.. (0x08|0x0044) plen 14 ... > HCI Event: Command Status (0x0f) plen 4 LE Periodic Advertising Create Sync (0x08|0x0044) ncmd 1 Status: Success (0x00) < HCI Command: LE Set Extended Sca.. (0x08|0x0041) plen 8 ... > HCI Event: Command Complete (0x0e) plen 4 LE Set Extended Scan Parameters (0x08|0x0041) ncmd 1 Status: Success (0x00) < HCI Command: LE Set Extended Sca.. (0x08|0x0042) plen 6 ... > HCI Event: Command Complete (0x0e) plen 4 LE Set Extended Scan Enable (0x08|0x0042) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 LE Extended Advertising Report (0x0d) ... > HCI Event: LE Meta Event (0x3e) plen 16 LE Periodic Advertising Sync Established (0x0e) ... < HCI Command: LE Broadcast Isoch.. (0x08|0x006b) plen 25 ... > HCI Event: Command Status (0x0f) plen 4 LE Broadcast Isochronous Group Create Sync (0x08|0x006b) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 17 LE Broadcast Isochronous Group Sync Estabilished (0x1d) ... Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
26afbd82 |
|
29-Jul-2019 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: Add initial implementation of CIS connections This adds the initial implementation of CIS connections and introduces the ISO packets/links. == Central: Set CIG Parameters, create a CIS and Setup Data Path == > tools/isotest -s <address> < HCI Command: LE Extended Create... (0x08|0x0043) plen 26 ... > HCI Event: Command Status (0x0f) plen 4 LE Extended Create Connection (0x08|0x0043) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 31 LE Enhanced Connection Complete (0x0a) ... < HCI Command: LE Create Connected... (0x08|0x0064) plen 5 ... > HCI Event: Command Status (0x0f) plen 4 LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 LE Connected Isochronous Stream Established (0x19) ... < HCI Command: LE Setup Isochronou.. (0x08|0x006e) plen 13 ... > HCI Event: Command Complete (0x0e) plen 6 LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 Status: Success (0x00) Handle: 257 < HCI Command: LE Setup Isochronou.. (0x08|0x006e) plen 13 ... > HCI Event: Command Complete (0x0e) plen 6 LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 Status: Success (0x00) Handle: 257 == Peripheral: Accept CIS and Setup Data Path == > tools/isotest -d HCI Event: LE Meta Event (0x3e) plen 7 LE Connected Isochronous Stream Request (0x1a) ... < HCI Command: LE Accept Co.. (0x08|0x0066) plen 2 ... > HCI Event: LE Meta Event (0x3e) plen 29 LE Connected Isochronous Stream Established (0x19) ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 ... > HCI Event: Command Complete (0x0e) plen 6 LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 Status: Success (0x00) Handle: 257 < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 ... > HCI Event: Command Complete (0x0e) plen 6 LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 Status: Success (0x00) Handle: 257 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
a86ddbff |
|
04-May-2022 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: Use bt_status to convert from errno If a command cannot be sent or there is a internal error an errno maybe set instead of a command status. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
629f66aa |
|
02-Jun-2022 |
Alain Michaud <alainm@chromium.org> |
Bluetooth: clear the temporary linkkey in hci_conn_cleanup If a hardware error occurs and the connections are flushed without a disconnection_complete event being signaled, the temporary linkkeys are not flushed. This change ensures that any outstanding flushable linkkeys are flushed when the connection are flushed from the hash table. Additionally, this also makes use of test_and_clear_bit to avoid multiple attempts to delete the link key that's already been flushed. Signed-off-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
c9f73a21 |
|
20-May-2022 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_conn: Fix hci_connect_le_sync The handling of connection failures shall be handled by the request completion callback as already done by hci_cs_le_create_conn, also make sure to use hci_conn_failed instead of hci_le_conn_failed as the later don't actually call hci_conn_del to cleanup. Link: https://github.com/bluez/bluez/issues/340 Fixes: 8e8b92ee60de5 ("Bluetooth: hci_sync: Add hci_le_create_conn_sync") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
05abad85 |
|
01-Apr-2022 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: HCI: Add HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN quirk This adds HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN quirk which can be used to mark HCI_Enhanced_Setup_Synchronous_Connection as broken even if its support command bit are set since some controller report it as supported but the command don't work properly with some configurations (e.g. BT_VOICE_TRANSPARENT/mSBC). Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
9b3628d7 |
|
22-Apr-2022 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_sync: Cleanup hci_conn if it cannot be aborted This attempts to cleanup the hci_conn if it cannot be aborted as otherwise it would likely result in having the controller and host stack out of sync with respect to connection handle. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
9fa6b4cd |
|
16-Mar-2022 |
Niels Dossche <dossche.niels@gmail.com> |
Bluetooth: call hci_le_conn_failed with hdev lock in hci_le_conn_failed hci_le_conn_failed function's documentation says that the caller must hold hdev->lock. The only callsite that does not hold that lock is hci_le_conn_failed. The other 3 callsites hold the hdev->lock very locally. The solution is to hold the lock during the call to hci_le_conn_failed. Fixes: 3c857757ef6e ("Bluetooth: Add directed advertising support through connect()") Signed-off-by: Niels Dossche <dossche.niels@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
d5ebaa7c |
|
23-Jan-2022 |
Soenke Huster <soenke.huster@eknoes.de> |
Bluetooth: hci_event: Ignore multiple conn complete events When one of the three connection complete events is received multiple times for the same handle, the device is registered multiple times which leads to memory corruptions. Therefore, consequent events for a single connection are ignored. The conn->state can hold different values, therefore HCI_CONN_HANDLE_UNSET is introduced to identify new connections. To make sure the events do not contain this or another invalid handle HCI_CONN_HANDLE_MAX and checks are introduced. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=215497 Signed-off-by: Soenke Huster <soenke.huster@eknoes.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
8e8b92ee |
|
22-Dec-2021 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_sync: Add hci_le_create_conn_sync This adds hci_le_create_conn_sync and make hci_le_connect use it instead of queueing multiple commands which may conflict with the likes of hci_update_passive_scan which uses hci_cmd_sync_queue. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
182ee45d |
|
27-Oct-2021 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_sync: Rework hci_suspend_notifier This makes hci_suspend_notifier use the hci_*_sync which can be executed synchronously which is allowed in the suspend_notifier and simplifies a lot of the handling since the status of each command can be checked inline so no other work need to be scheduled thus can be performed without using of a state machine. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
abfeea47 |
|
27-Oct-2021 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_sync: Convert MGMT_OP_START_DISCOVERY This make use of hci_cmd_sync_queue for MGMT_OP_START_DISCOVERY, MGMT_OP_START_SERVICE_DISCOVERY and MGMT_OP_STOP_DISCOVERY to use hci_cmd_sync_queue so they no longer depend on hdev->discov_update work to send any commands. Tested with: tools/mgmt-tester -s "Start Discovery" Test Summary ------------ Start Discovery - Not powered 1 Passed Start Discovery - Invalid parameters 1 Passed Start Discovery - Not supported 1 Passed Start Discovery - Success 1 Passed Start Discovery - Success 2 Passed Start Discovery - Power Off 1 Passed Start Discovery BREDR LE - (Ext Scan Enable) Passed Start Discovery LE - (Ext Scan Enable) Passed Start Discovery LE - (Ext Scan Param) Passed Start Discovery - (2m, Scan Param) Passed Start Discovery - (coded, Scan Param) Passed Start Discovery - (1m, 2m, coded, Scan Param) Passed LL Privacy - Start Discovery 1 (Disable RL) Passed LL Privacy - Start Discovery 2 (Disable RL) Passed Total: 14, Passed: 14 (100.0%), Failed: 0, Not Run: 0 tools/mgmt-tester -s "Start Service" Test Summary ------------ Start Service Discovery - Not powered 1 Passed Start Service Discovery - Invalid parameters 1 Passed Start Service Discovery - Not supported 1 Passed Start Service Discovery - Success 1 Passed Start Service Discovery - Success 2 Passed Total: 5, Passed: 5 (100.0%), Failed: 0, Not Run: 0 tools/mgmt-tester -s "Stop Discovery" Test Summary ------------ Stop Discovery - Success 1 Passed Stop Discovery - BR/EDR (Inquiry) Success 1 Passed Stop Discovery - Rejected 1 Passed Stop Discovery - Invalid parameters 1 Passed Stop Discovery - (Ext Scan Disable) Passed Total: 5, Passed: 5 (100.0%), Failed: 0, Not Run: 0 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
5bee2fd6 |
|
27-Oct-2021 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: hci_sync: Rework background scan This replaces the use of hci_update_background_scan with hci_update_passive_scan which runs from cmd_work_sync and deal properly with resolving list when LL privacy is enabled. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
904c139a |
|
07-Sep-2021 |
Kiran K <kiran.k@intel.com> |
Bluetooth: Add support for msbc coding format In Enhanced_Setup_Synchronous_Command, add support for msbc coding format Signed-off-by: Kiran K <kiran.k@intel.com> Reviewed-by: Chethan T N <chethan.tumkur.narayan@intel.com> Reviewed-by: Srivatsa Ravishankar <ravishankar.srivatsa@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
9798fbde |
|
07-Sep-2021 |
Kiran K <kiran.k@intel.com> |
Bluetooth: Configure codec for HFP offload use case For HFP offload use case, codec needs to be configured before opening SCO connection. This patch sends HCI_CONFIGURE_DATA_PATH command to configure doec before opening SCO connection. Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
b2af264a |
|
07-Sep-2021 |
Kiran K <kiran.k@intel.com> |
Bluetooth: Add support for HCI_Enhanced_Setup_Synchronous_Connection command < HCI Command: Enhanced Setup Synchronous Connection (0x01|0x003d) plen 59 Handle: 256 Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Packet type: 0x0380 3-EV3 may not be used 2-EV5 may not be used 3-EV5 may not be used Retransmission effort: Optimize for link quality (0x02) > HCI Event: Command Status (0x0f) plen 4 Enhanced Setup Synchronous Connection (0x01|0x003d) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 Status: Success (0x00) Handle: 257 Address: CC:98:8B:92:04:FD (SONY Visual Products Inc.) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x06 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) Signed-off-by: Kiran K <kiran.k@intel.com> Reviewed-by: Chethan T N <chethan.tumkur.narayan@intel.com> Reviewed-by: Srivatsa Ravishankar <ravishankar.srivatsa@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
#
d850bf08 |
|
30-Aug-2021 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: Fix using RPA when address has been resolved When connecting to a device using an RPA if the address has been resolved by the controller (types 0x02 and 0x03) the identity address shall be used as the actual RPA in the advertisement won't be visible to the host. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
74be523c |
|
04-Jun-2021 |
Archie Pusaka <apusaka@chromium.org> |
Bluetooth: use inclusive language in HCI role comments This patch replaces some non-inclusive terms based on the appropriate language mapping table compiled by the Bluetooth SIG: https://specificationrefs.bluetooth.com/language-mapping/Appropriate_Language_Mapping_Table.pdf Specifically, these terms are replaced: master -> initiator (for smp) or central (everything else) slave -> responder (for smp) or peripheral (everything else) The #define preprocessor terms are unchanged for now to not disturb dependent APIs. Signed-off-by: Archie Pusaka <apusaka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
6397729b |
|
31-May-2021 |
Archie Pusaka <apusaka@chromium.org> |
Bluetooth: use inclusive language to describe CPB This patch replaces some non-inclusive terms based on the appropriate language mapping table compiled by the Bluetooth SIG: https://specificationrefs.bluetooth.com/language-mapping/Appropriate_Language_Mapping_Table.pdf Specifically, these terms are replaced when describing the connectionless peripheral broadcast feature: master -> central slave -> peripheral Signed-off-by: Archie Pusaka <apusaka@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
91641b79 |
|
02-Jun-2021 |
Zheng Yongjun <zhengyongjun3@huawei.com> |
Bluetooth: Fix spelling mistakes Fix some spelling mistakes in comments: udpate ==> update retreive ==> retrieve accidentially ==> accidentally correspondig ==> corresponding adddress ==> address estabilish ==> establish commplete ==> complete Unkown ==> Unknown triggerd ==> triggered transtion ==> transition Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
17486960 |
|
16-Mar-2021 |
Jiri Kosina <jkosina@suse.cz> |
Bluetooth: avoid deadlock between hci_dev->lock and socket lock Commit eab2404ba798 ("Bluetooth: Add BT_PHY socket option") added a dependency between socket lock and hci_dev->lock that could lead to deadlock. It turns out that hci_conn_get_phy() is not in any way relying on hdev being immutable during the runtime of this function, neither does it even look at any of the members of hdev, and as such there is no need to hold that lock. This fixes the lockdep splat below: ====================================================== WARNING: possible circular locking dependency detected 5.12.0-rc1-00026-g73d464503354 #10 Not tainted ------------------------------------------------------ bluetoothd/1118 is trying to acquire lock: ffff8f078383c078 (&hdev->lock){+.+.}-{3:3}, at: hci_conn_get_phy+0x1c/0x150 [bluetooth] but task is already holding lock: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}: lock_sock_nested+0x72/0xa0 l2cap_sock_ready_cb+0x18/0x70 [bluetooth] l2cap_config_rsp+0x27a/0x520 [bluetooth] l2cap_sig_channel+0x658/0x1330 [bluetooth] l2cap_recv_frame+0x1ba/0x310 [bluetooth] hci_rx_work+0x1cc/0x640 [bluetooth] process_one_work+0x244/0x5f0 worker_thread+0x3c/0x380 kthread+0x13e/0x160 ret_from_fork+0x22/0x30 -> #2 (&chan->lock#2/1){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0x33a/0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #1 (&conn->chan_lock){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0x322/0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #0 (&hdev->lock){+.+.}-{3:3}: __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 __mutex_lock+0xa3/0xa10 hci_conn_get_phy+0x1c/0x150 [bluetooth] l2cap_sock_getsockopt+0x5a9/0x610 [bluetooth] __sys_getsockopt+0xcc/0x200 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: &hdev->lock --> &chan->lock#2/1 --> sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock(&chan->lock#2/1); lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock(&hdev->lock); *** DEADLOCK *** 1 lock held by bluetoothd/1118: #0: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 [bluetooth] stack backtrace: CPU: 3 PID: 1118 Comm: bluetoothd Not tainted 5.12.0-rc1-00026-g73d464503354 #10 Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017 Call Trace: dump_stack+0x7f/0xa1 check_noncircular+0x105/0x120 ? __lock_acquire+0x147a/0x1a50 __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? __lock_acquire+0x2e1/0x1a50 ? lock_is_held_type+0xb4/0x120 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] __mutex_lock+0xa3/0xa10 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? lock_acquire+0x277/0x3d0 ? mark_held_locks+0x49/0x70 ? mark_held_locks+0x49/0x70 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] hci_conn_get_phy+0x1c/0x150 [bluetooth] l2cap_sock_getsockopt+0x5a9/0x610 [bluetooth] __sys_getsockopt+0xcc/0x200 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fb73df33eee Code: 48 8b 0d 85 0f 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 37 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 52 0f 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007fffcfbbbf08 EFLAGS: 00000203 ORIG_RAX: 0000000000000037 RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007fb73df33eee RDX: 000000000000000e RSI: 0000000000000112 RDI: 0000000000000018 RBP: 0000000000000000 R08: 00007fffcfbbbf44 R09: 0000000000000000 R10: 00007fffcfbbbf3c R11: 0000000000000203 R12: 0000000000000000 R13: 0000000000000018 R14: 0000000000000000 R15: 0000556fcefc70d0 Fixes: eab2404ba798 ("Bluetooth: Add BT_PHY socket option") Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
5cb08553 |
|
01-Mar-2021 |
Abhishek Pandit-Subedi <abhishekpandit@chromium.org> |
Bluetooth: Notify suspend on le conn failed When suspending, Bluetooth disconnects all connected peers devices. If an LE connection is started but isn't completed, we will see an LE Create Connection Cancel instead of an HCI disconnect. This just adds a check to see if an LE cancel was the last disconnected device and wake the suspend thread when that is the case. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Archie Pusaka <apusaka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
8b1c324c |
|
29-Jan-2021 |
Yu Liu <yudiliu@google.com> |
Bluetooth: Skip eSCO 2M params when not supported If a peer device doesn't support eSCO 2M we should skip the params that use it when setting up sync connection since they will always fail. Signed-off-by: Yu Liu <yudiliu@google.com> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
89e65975 |
|
09-Dec-2020 |
Sonny Sasaka <sonnysasaka@chromium.org> |
Bluetooth: Cancel Inquiry before Create Connection Many controllers do not allow HCI Create Connection while it is doing Inquiry. This patch adds Inquiry Cancel before Create Connection in this case to allow the controller to do Create Connection. User space will be aware of this Inquiry cancellation and they may issue another discovery request afterwards. Sample Command Disallowed response of HCI Create Connection: < HCI Command: Inquiry (0x01|0x0001) plen 5 Access code: 0x9e8b33 (General Inquiry) Length: 10.24s (0x08) Num responses: 0 > HCI Event: Command Status (0x0f) plen 4 Inquiry (0x01|0x0001) ncmd 2 Status: Success (0x00) < HCI Command: Create Connection (0x01|0x0005) plen 13 Address: XX:XX:XX:XX:XX:XX Packet type: 0xcc18 Page scan repetition mode: R2 (0x02) Page scan mode: Mandatory (0x00) Clock offset: 0x0000 Role switch: Allow slave (0x01) > HCI Event: Command Status (0x0f) plen 4 Create Connection (0x01|0x0005) ncmd 1 Status: Success (0x00) > HCI Event: Connect Complete (0x03) plen 11 Status: Command Disallowed (0x0c) Handle: 65535 Address: XX:XX:XX:XX:XX:XX Link type: ACL (0x01) Encryption: Disabled (0x00) Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Sonny Sasaka <sonnysasaka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
2943d8ed |
|
06-Nov-2020 |
Daniel Winkler <danielwinkler@google.com> |
Bluetooth: Resume advertising after LE connection When an LE connection request is made, advertising is disabled and never resumed. When a client has an active advertisement, this is disruptive. This change adds resume logic for client-configured (non-directed) advertisements after the connection attempt. The patch was tested by registering an advertisement, initiating an LE connection from a remote peer, and verifying that the advertisement is re-activated after the connection is established. This is performed on Hatch and Kukui Chromebooks. Signed-off-by: Daniel Winkler <danielwinkler@google.com> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
bb6d6895 |
|
17-Sep-2020 |
Randy Dunlap <rdunlap@infradead.org> |
net: bluetooth: delete duplicated words Drop repeated words in net/bluetooth/. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
5c49bcce |
|
23-Jul-2020 |
Sathish Narasimman <nsathish41@gmail.com> |
Bluetooth: Enable/Disable address resolution during le create conn In this patch if le_create_conn process is started restrict to disable address resolution and same is disabled during le_enh_connection_complete Signed-off-by: Sathish Narasimman <sathish.narasimman@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
37adf701 |
|
14-Jul-2020 |
Daniel Winkler <danielwinkler@google.com> |
Bluetooth: Add per-instance adv disable/remove Add functionality to disable and remove advertising instances, and use that functionality in MGMT add/remove advertising calls. Currently, advertising is globally-disabled, i.e. all instances are disabled together, even if hardware offloading is available. This patch adds functionality to disable and remove individual adv instances, solving two issues: 1. On new advertisement registration, a global disable was done, and then only the new instance was enabled. This meant only the newest instance was actually enabled. 2. On advertisement removal, the structure was removed, but the instance was never disabled or removed, which is incorrect with hardware offload support. Signed-off-by: Daniel Winkler <danielwinkler@google.com> Reviewed-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Alain Michaud <alainm@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
8746f135 |
|
20-May-2020 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: Disconnect if E0 is used for Level 4 E0 is not allowed with Level 4: BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part C page 1319: '128-bit equivalent strength for link and encryption keys required using FIPS approved algorithms (E0 not allowed, SAFER+ not allowed, and P-192 not allowed; encryption key not shortened' SC enabled: > HCI Event: Read Remote Extended Features (0x23) plen 13 Status: Success (0x00) Handle: 256 Page: 1/2 Features: 0x0b 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Secure Simple Pairing (Host Support) LE Supported (Host) Secure Connections (Host Support) > HCI Event: Encryption Change (0x08) plen 4 Status: Success (0x00) Handle: 256 Encryption: Enabled with AES-CCM (0x02) SC disabled: > HCI Event: Read Remote Extended Features (0x23) plen 13 Status: Success (0x00) Handle: 256 Page: 1/2 Features: 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Secure Simple Pairing (Host Support) LE Supported (Host) > HCI Event: Encryption Change (0x08) plen 4 Status: Success (0x00) Handle: 256 Encryption: Enabled with E0 (0x01) [May 8 20:23] Bluetooth: hci0: Invalid security: expect AES but E0 was used < HCI Command: Disconnect (0x01|0x0006) plen 3 Handle: 256 Reason: Authentication Failure (0x05) Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
76b13996 |
|
17-Jun-2020 |
Manish Mandlik <mmandlik@google.com> |
Bluetooth: Terminate the link if pairing is cancelled If user decides to cancel the ongoing pairing process (e.g. by clicking the cancel button on pairing/passkey window), abort any ongoing pairing and then terminate the link if it was created because of the pair device action. Signed-off-by: Manish Mandlik <mmandlik@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
10873f99 |
|
10-Jun-2020 |
Alain Michaud <alainm@chromium.org> |
Bluetooth: centralize default value initialization. This patch centralized the initialization of default parameters. This is required to allow clients to more easily customize the default system parameters. Signed-off-by: Alain Michaud <alainm@chromium.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
755dfcbc |
|
19-May-2020 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: Fix assuming EIR flags can result in SSP authentication EIR flags should just hint if SSP may be supported but we shall verify this with use of the actual features as the SSP bits may be disabled in the lower layers which would result in legacy authentication to be used. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
1f8330ea |
|
03-Apr-2020 |
Sathish Narsimman <nsathish41@gmail.com> |
Bluetooth: add support to notify using SCO air mode notifying using HCI_NOTIFY_CONN_ADD for SCO connection is generic in case of mSBC audio. To differntiate SCO air mode introducing HCI_NOTIFY_ENABLE_SCO_CVSD and HCI_NOTIFY_ENABLE_SCO_TRANSP. Signed-off-by: Sathish Narsimman <sathish.narasimman@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
c3bed4de |
|
23-Feb-2020 |
Sathish Narsimman <nsathish41@gmail.com> |
Bluetooth: During le_conn_timeout disable EXT_ADV Disabling LE_LEGACY_ADV when LE_EXT_ADV is enabled causes 'command disallowed . This patch fixes that issue and disables EXT_ADV if enabled. Signed-off-by: Sathish Narsimman <sathish.narasimman@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
a9e45698 |
|
23-Feb-2020 |
Sathish Narsimman <nsathish41@gmail.com> |
Bluetooth: Remove adv set for directed advertising Extended advertising Data is set during bluetooth initialization by default which causes InvalidHCICommandParameters when setting Extended advertising parameters. As per Core Spec 5.2 Vol 2, PART E, Sec 7.8.53, for advertising_event_property LE_LEGACY_ADV_DIRECT_IND does not supports advertising data when the advertising set already contains some, the controller shall return erroc code 'InvalidHCICommandParameters(0x12). So it is required to remove adv set for handle 0x00. since we use instance 0 for directed adv. Signed-off-by: Sathish Narsimman <sathish.narasimman@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
05bd80a1 |
|
17-Feb-2020 |
Sathish Narsimman <nsathish41@gmail.com> |
Bluetooth: Disable Extended Adv if enabled Disabling LEGACY_ADV when EXT_ADV is enabled causes 'command disallowed' during DIRECTED_ADV. This Patch fixes this issue. Signed-off-by: Sathish Narsimman <sathish.narasimman@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
eab2404b |
|
14-Feb-2020 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: Add BT_PHY socket option This adds BT_PHY socket option (read-only) which can be used to read the PHYs in use by the underline connection. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
d088337c |
|
21-Nov-2019 |
Navid Emamdoost <navid.emamdoost@gmail.com> |
Bluetooth: Fix memory leak in hci_connect_le_scan In the implementation of hci_connect_le_scan() when conn is added via hci_conn_add(), if hci_explicit_conn_params_set() fails the allocated memory for conn is leaked. Use hci_conn_del() to release it. Fixes: f75113a26008 ("Bluetooth: add hci_connect_le_scan") Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
4c371bb9 |
|
02-Oct-2019 |
Szymon Janc <szymon.janc@codecoup.pl> |
Bluetooth: Workaround directed advertising bug in Broadcom controllers It appears that some Broadcom controllers (eg BCM20702A0) reject LE Set Advertising Parameters command if advertising intervals provided are not within range for undirected and low duty directed advertising. Workaround this bug by populating min and max intervals with 'valid' values. < HCI Command: LE Set Advertising Parameters (0x08|0x0006) plen 15 Min advertising interval: 0.000 msec (0x0000) Max advertising interval: 0.000 msec (0x0000) Type: Connectable directed - ADV_DIRECT_IND (high duty cycle) (0x01) Own address type: Public (0x00) Direct address type: Random (0x01) Direct address: E2:F0:7B:9F:DC:F4 (Static) Channel map: 37, 38, 39 (0x07) Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00) > HCI Event: Command Complete (0x0e) plen 4 LE Set Advertising Parameters (0x08|0x0006) ncmd 1 Status: Invalid HCI Command Parameters (0x12) Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl> Tested-by: Sören Beye <linux@hypfer.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
1d0fac2c |
|
03-Jun-2019 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: Use controller sets when available This makes use of controller sets when using Extended Advertising feature thus offloading the scheduling to the controller. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
302975cb |
|
21-Jun-2019 |
Spoorthi Ravishankar Koppad <spoorthix.k@intel.com> |
Bluetooth: Add support for LE ping feature Changes made to add HCI Write Authenticated Payload timeout command for LE Ping feature. As per the Core Specification 5.0 Volume 2 Part E Section 7.3.94, the following code changes implements HCI Write Authenticated Payload timeout command for LE Ping feature. Signed-off-by: Spoorthi Ravishankar Koppad <spoorthix.k@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
693cd8ce |
|
22-Jun-2019 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Fix regression with minimum encryption key size alignment When trying to align the minimum encryption key size requirement for Bluetooth connections, it turns out doing this in a central location in the HCI connection handling code is not possible. Original Bluetooth version up to 2.0 used a security model where the L2CAP service would enforce authentication and encryption. Starting with Bluetooth 2.1 and Secure Simple Pairing that model has changed into that the connection initiator is responsible for providing an encrypted ACL link before any L2CAP communication can happen. Now connecting Bluetooth 2.1 or later devices with Bluetooth 2.0 and before devices are causing a regression. The encryption key size check needs to be moved out of the HCI connection handling into the L2CAP channel setup. To achieve this, the current check inside hci_conn_security() has been moved into l2cap_check_enc_key_size() helper function and then called from four decisions point inside L2CAP to cover all combinations of Secure Simple Pairing enabled devices and device using legacy pairing and legacy service security model. Fixes: d5bb334a8e17 ("Bluetooth: Align minimum encryption key size for LE and BR/EDR connections") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203643 Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
d5bb334a |
|
24-Apr-2019 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Align minimum encryption key size for LE and BR/EDR connections The minimum encryption key size for LE connections is 56 bits and to align LE with BR/EDR, enforce 56 bits of minimum encryption key size for BR/EDR connections as well. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Cc: stable@vger.kernel.org
|
#
a73c046a |
|
19-Jul-2018 |
Jaganath Kanakkassery <jaganath.k.os@gmail.com> |
Bluetooth: Implement Set ADV set random address This basically sets the random address for the adv instance Random address can be set only if the instance is created which is done in Set ext adv param. Random address and rpa expire timer and flags have been added to adv instance which will be used when the respective instance is scheduled. This introduces a hci_get_random_address() which returns the own address type and random address (rpa or nrpa) based on the instance flags and hdev flags. New function is required since own address type should be known before setting adv params but address can be set only after setting params. < HCI Command: LE Set Advertising Set Random Address (0x08|0x0035) plen 7 Advertising handle: 0x00 Advertising random address: 3C:8E:56:9B:77:84 (OUI 3C-8E-56) > HCI Event: Command Complete (0x0e) plen 4 LE Set Advertising Set Random Address (0x08|0x0035) ncmd 1 Status: Success (0x00) Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
075e40b7 |
|
19-Jul-2018 |
Jaganath Kanakkassery <jaganath.k.os@gmail.com> |
Bluetooth: Use ext adv for directed adv This patch does extended advertising for directed advertising if the controller supportes. Instance 0 is used for directed advertising. Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
4e6e99e9 |
|
19-Jul-2018 |
Jaganath Kanakkassery <jaganath.k.os@gmail.com> |
Bluetooth: Use selected PHYs in extended connect Use the selected PHYs by Set PHY Configuration management command in extended create connection. Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
4d94f95d |
|
06-Jul-2018 |
Jaganath Kanakkassery <jaganath.k.os@gmail.com> |
Bluetooth: Use extended LE Connection if supported This implements extended LE craete connection and enhanced LE conn complete event if the controller supports. For now it is as good as legacy LE connection and event as no new features in the extended connection is handled. < HCI Command: LE Extended Create Connection (0x08|0x0043) plen 26 Filter policy: White list is not used (0x00) Own address type: Public (0x00) Peer address type: Random (0x01) Peer address: DB:7E:2E:1D:85:E8 (Static) Initiating PHYs: 0x01 Entry 0: LE 1M Scan interval: 60.000 msec (0x0060) Scan window: 60.000 msec (0x0060) Min connection interval: 50.00 msec (0x0028) Max connection interval: 70.00 msec (0x0038) Connection latency: 0 (0x0000) Supervision timeout: 420 msec (0x002a) Min connection length: 0.000 msec (0x0000) Max connection length: 0.000 msec (0x0000) > HCI Event: Command Status (0x0f) plen 4 LE Extended Create Connection (0x08|0x0043) ncmd 2 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 31 LE Enhanced Connection Complete (0x0a) Status: Success (0x00) Handle: 3585 Role: Master (0x00) Peer address type: Random (0x01) Peer address: DB:7E:2E:1D:85:E8 (Static) Local resolvable private address: 00:00:00:00:00:00 (Non-Resolvable) Peer resolvable private address: 00:00:00:00:00:00 (Non-Resolvable) Connection interval: 67.50 msec (0x0036) Connection latency: 0 (0x0000) Supervision timeout: 420 msec (0x002a) Master clock accuracy: 0x00 @ MGMT Event: Device Connected (0x000b) plen 40 LE Address: DB:7E:2E:1D:85:E8 (Static) Flags: 0x00000000 Data length: 27 Name (complete): Designer Mouse Appearance: Mouse (0x03c2) Flags: 0x05 LE Limited Discoverable Mode BR/EDR Not Supported 16-bit Service UUIDs (complete): 1 entry Human Interface Device (0x1812) Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
082f2300 |
|
03-Apr-2018 |
Szymon Janc <szymon.janc@codecoup.pl> |
Bluetooth: Fix connection if directed advertising and privacy is used Local random address needs to be updated before creating connection if RPA from LE Direct Advertising Report was resolved in host. Otherwise remote device might ignore connection request due to address mismatch. This was affecting following qualification test cases: GAP/CONN/SCEP/BV-03-C, GAP/CONN/GCEP/BV-05-C, GAP/CONN/DCEP/BV-05-C Before patch: < HCI Command: LE Set Random Address (0x08|0x0005) plen 6 #11350 [hci0] 84680.231216 Address: 56:BC:E8:24:11:68 (Resolvable) Identity type: Random (0x01) Identity: F2:F1:06:3D:9C:42 (Static) > HCI Event: Command Complete (0x0e) plen 4 #11351 [hci0] 84680.246022 LE Set Random Address (0x08|0x0005) ncmd 1 Status: Success (0x00) < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 #11352 [hci0] 84680.246417 Type: Passive (0x00) Interval: 60.000 msec (0x0060) Window: 30.000 msec (0x0030) Own address type: Random (0x01) Filter policy: Accept all advertisement, inc. directed unresolved RPA (0x02) > HCI Event: Command Complete (0x0e) plen 4 #11353 [hci0] 84680.248854 LE Set Scan Parameters (0x08|0x000b) ncmd 1 Status: Success (0x00) < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #11354 [hci0] 84680.249466 Scanning: Enabled (0x01) Filter duplicates: Enabled (0x01) > HCI Event: Command Complete (0x0e) plen 4 #11355 [hci0] 84680.253222 LE Set Scan Enable (0x08|0x000c) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 18 #11356 [hci0] 84680.458387 LE Direct Advertising Report (0x0b) Num reports: 1 Event type: Connectable directed - ADV_DIRECT_IND (0x01) Address type: Random (0x01) Address: 53:38:DA:46:8C:45 (Resolvable) Identity type: Public (0x00) Identity: 11:22:33:44:55:66 (OUI 11-22-33) Direct address type: Random (0x01) Direct address: 7C:D6:76:8C:DF:82 (Resolvable) Identity type: Random (0x01) Identity: F2:F1:06:3D:9C:42 (Static) RSSI: -74 dBm (0xb6) < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #11357 [hci0] 84680.458737 Scanning: Disabled (0x00) Filter duplicates: Disabled (0x00) > HCI Event: Command Complete (0x0e) plen 4 #11358 [hci0] 84680.469982 LE Set Scan Enable (0x08|0x000c) ncmd 1 Status: Success (0x00) < HCI Command: LE Create Connection (0x08|0x000d) plen 25 #11359 [hci0] 84680.470444 Scan interval: 60.000 msec (0x0060) Scan window: 60.000 msec (0x0060) Filter policy: White list is not used (0x00) Peer address type: Random (0x01) Peer address: 53:38:DA:46:8C:45 (Resolvable) Identity type: Public (0x00) Identity: 11:22:33:44:55:66 (OUI 11-22-33) Own address type: Random (0x01) Min connection interval: 30.00 msec (0x0018) Max connection interval: 50.00 msec (0x0028) Connection latency: 0 (0x0000) Supervision timeout: 420 msec (0x002a) Min connection length: 0.000 msec (0x0000) Max connection length: 0.000 msec (0x0000) > HCI Event: Command Status (0x0f) plen 4 #11360 [hci0] 84680.474971 LE Create Connection (0x08|0x000d) ncmd 1 Status: Success (0x00) < HCI Command: LE Create Connection Cancel (0x08|0x000e) plen 0 #11361 [hci0] 84682.545385 > HCI Event: Command Complete (0x0e) plen 4 #11362 [hci0] 84682.551014 LE Create Connection Cancel (0x08|0x000e) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 19 #11363 [hci0] 84682.551074 LE Connection Complete (0x01) Status: Unknown Connection Identifier (0x02) Handle: 0 Role: Master (0x00) Peer address type: Public (0x00) Peer address: 00:00:00:00:00:00 (OUI 00-00-00) Connection interval: 0.00 msec (0x0000) Connection latency: 0 (0x0000) Supervision timeout: 0 msec (0x0000) Master clock accuracy: 0x00 After patch: < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 #210 [hci0] 667.152459 Type: Passive (0x00) Interval: 60.000 msec (0x0060) Window: 30.000 msec (0x0030) Own address type: Random (0x01) Filter policy: Accept all advertisement, inc. directed unresolved RPA (0x02) > HCI Event: Command Complete (0x0e) plen 4 #211 [hci0] 667.153613 LE Set Scan Parameters (0x08|0x000b) ncmd 1 Status: Success (0x00) < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #212 [hci0] 667.153704 Scanning: Enabled (0x01) Filter duplicates: Enabled (0x01) > HCI Event: Command Complete (0x0e) plen 4 #213 [hci0] 667.154584 LE Set Scan Enable (0x08|0x000c) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 18 #214 [hci0] 667.182619 LE Direct Advertising Report (0x0b) Num reports: 1 Event type: Connectable directed - ADV_DIRECT_IND (0x01) Address type: Random (0x01) Address: 50:52:D9:A6:48:A0 (Resolvable) Identity type: Public (0x00) Identity: 11:22:33:44:55:66 (OUI 11-22-33) Direct address type: Random (0x01) Direct address: 7C:C1:57:A5:B7:A8 (Resolvable) Identity type: Random (0x01) Identity: F4:28:73:5D:38:B0 (Static) RSSI: -70 dBm (0xba) < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #215 [hci0] 667.182704 Scanning: Disabled (0x00) Filter duplicates: Disabled (0x00) > HCI Event: Command Complete (0x0e) plen 4 #216 [hci0] 667.183599 LE Set Scan Enable (0x08|0x000c) ncmd 1 Status: Success (0x00) < HCI Command: LE Set Random Address (0x08|0x0005) plen 6 #217 [hci0] 667.183645 Address: 7C:C1:57:A5:B7:A8 (Resolvable) Identity type: Random (0x01) Identity: F4:28:73:5D:38:B0 (Static) > HCI Event: Command Complete (0x0e) plen 4 #218 [hci0] 667.184590 LE Set Random Address (0x08|0x0005) ncmd 1 Status: Success (0x00) < HCI Command: LE Create Connection (0x08|0x000d) plen 25 #219 [hci0] 667.184613 Scan interval: 60.000 msec (0x0060) Scan window: 60.000 msec (0x0060) Filter policy: White list is not used (0x00) Peer address type: Random (0x01) Peer address: 50:52:D9:A6:48:A0 (Resolvable) Identity type: Public (0x00) Identity: 11:22:33:44:55:66 (OUI 11-22-33) Own address type: Random (0x01) Min connection interval: 30.00 msec (0x0018) Max connection interval: 50.00 msec (0x0028) Connection latency: 0 (0x0000) Supervision timeout: 420 msec (0x002a) Min connection length: 0.000 msec (0x0000) Max connection length: 0.000 msec (0x0000) > HCI Event: Command Status (0x0f) plen 4 #220 [hci0] 667.186558 LE Create Connection (0x08|0x000d) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 19 #221 [hci0] 667.485824 LE Connection Complete (0x01) Status: Success (0x00) Handle: 0 Role: Master (0x00) Peer address type: Random (0x01) Peer address: 50:52:D9:A6:48:A0 (Resolvable) Identity type: Public (0x00) Identity: 11:22:33:44:55:66 (OUI 11-22-33) Connection interval: 50.00 msec (0x0028) Connection latency: 0 (0x0000) Supervision timeout: 420 msec (0x002a) Master clock accuracy: 0x07 @ MGMT Event: Device Connected (0x000b) plen 13 {0x0002} [hci0] 667.485996 LE Address: 11:22:33:44:55:66 (OUI 11-22-33) Flags: 0x00000000 Data length: 0 Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org
|
#
2064ee33 |
|
30-Oct-2017 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Use bt_dev_err and bt_dev_info when possible In case of using BT_ERR and BT_INFO, convert to bt_dev_err and bt_dev_info when possible. This allows for controller specific reporting. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
f17d858e |
|
24-Oct-2017 |
Jaganath Kanakkassery <jaganath.k.os@gmail.com> |
Bluetooth: Fix potential memory leak If command is added to req then it should be freed in case if hdev is down or HCI_ADVERTISING flag is set. This introduces a helper in hci_request to purge the cmd_q to make cmd_q internal to hci_request which is used to fix the leak. This also replace accessing of cmd_q in hci_conn with the new helper. Signed-off-by: Jaganath Kanakkassery <jaganathx.kanakkassery@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
39385cb5 |
|
12-Nov-2016 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix using the correct source address type The hci_get_route() API is used to look up local HCI devices, however so far it has been incapable of dealing with anything else than the public address of HCI devices. This completely breaks with LE-only HCI devices that do not come with a public address, but use a static random address instead. This patch exteds the hci_get_route() API with a src_type parameter that's used for comparing with the right address of each HCI device. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
ca8bee5d |
|
05-Jul-2016 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Rename HCI_BREDR into HCI_PRIMARY The HCI_BREDR naming is confusing since it actually stands for Primary Bluetooth Controller. Which is a term that has been used in the latest standard. However from a legacy point of view there only really have been Basic Rate (BR) and Enhanced Data Rate (EDR). Recent versions of Bluetooth introduced Low Energy (LE) and made this terminology a little bit confused since Dual Mode Controllers include BR/EDR and LE. To simplify this the name HCI_PRIMARY stands for the Primary Controller which can be a single mode or dual mode controller. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
82a37ade |
|
09-Mar-2016 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Add support for limited privacy mode Introduce a limited privacy mode indicated by value 0x02 to the mgmt Set Privacy command. With value 0x02 the kernel will use privacy mode with a resolvable private address. In case the controller is bondable and discoverable the identity address will be used. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
eec7a01d |
|
09-Mar-2016 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Move memset closer to where it's needed Minor fix to not do the memset until the variable it clears is actually used. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
acb9f911 |
|
02-Dec-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Don't treat connection timeout as a failure When we're doing background scanning and connection attempts it's possible we timeout trying to connect and go back to scanning again. The timeout triggers a HCI_LE_Create_Connection_Cancel which will trigger a Connection Complete with "Unknown Connection Identifier" error status. Since we go back to scanning this isn't really a failure and shouldn't be presented as such to user space through mgmt. The exception to this is if the connection attempt was due to an explicit request on an L2CAP socket (indicated by params->explicit_connect being true). Since the socket will get an error it's consistent to also notify the failure on mgmt in this case. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
2f99536a |
|
02-Dec-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Use continuous scanning when creating LE connections All LE connections are now triggered through a preceding passive scan and waiting for a connectable advertising report. This means we've got the best possible guarantee that the device is within range and should be able to request the controller to perform continuous scanning. This way we minimize the risk that we miss out on any advertising packets. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # 4.3+
|
#
f2252570 |
|
17-Nov-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Move advertising instance management to hci_request.c This paves the way for eventually performing advertising changes through the hdev->req_workqueue. Some new APIs need to be exposed from mgmt.c to hci_request.c and vice-versa, but many of them will go away once hdev->req_workqueue gets used. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
e2caced4 |
|
11-Nov-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Remove conn_unfinished variable from hci_connect_le() The conn_unfinished variable makes the entire logic of hci_connect_le() rather confusing. By restructuring and clarifying the logic we can actually remove the conn_unfinished variable and still keep the same behavior. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
658aead9 |
|
11-Nov-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Move check for ongoing connect earlier in hci_connect_le() This helps simplify the logic in further patches (less cleanups to do in this failure branch). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
0ad06aa6 |
|
11-Nov-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix specifying role for LE connections The hci_connect_le_scan() is (as the name implies) a master/central role API, so it makes no sense in passing a role parameter to it. At the same time this patch also fixes the direct advertising support for LE L2CAP sockets where we now call the more appropriate hci_le_connect() API if slave/peripheral role is desired. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
84235d22 |
|
10-Nov-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Use req_workqueue for explicit connect requests Since explicit connect requests are also a sub-category of passive scan updates, run them through the same workqueue as the other passive scan changes. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
0ebc1818 |
|
06-Nov-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Add clarifying comment why schedule_work is used It's not obvious why schedule_work is used instead of queue_work. Add a comment explaining why. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
88d07feb |
|
22-Oct-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Make hci_disconnect() behave correctly for all states There are a few places that don't explicitly check the connection state before calling hci_disconnect(). To make this API do the right thing take advantage of the new hci_abort_conn() API and also make sure to only read the clock offset if we're really connected. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
89e0ccc8 |
|
22-Oct-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Take advantage of connection abort helpers Convert the various places mapping connection state to disconnect/cancel HCI command to use the new hci_abort_conn helper API. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
17bc08f0 |
|
21-Oct-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Remove unnecessary hci_explicit_connect_lookup function There's only one user of this helper which can be replaces with a call to hci_pend_le_action_lookup() and a check for params->explicit_connect. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
b5c2b621 |
|
21-Oct-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Add hdev helper variable to hci_le_create_connection_cancel The hci_le_create_connection_cancel() function needs to use the hdev pointer in many places so add a variable for it to avoid the need to dereference the hci_conn every time. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
9d4c1cc1 |
|
21-Oct-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Use hci_conn_hash_lookup_le() when possible Use the new hci_conn_hash_lookup_le() API to look up LE connections. This way we're guaranteed exact matches that also take into account the address type. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
8ce783dc |
|
21-Oct-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix missing hdev locking for LE scan cleanup The hci_conn objects don't have a dedicated lock themselves but rely on the caller to hold the hci_dev lock for most types of access. The hci_conn_timeout() function has so far sent certain HCI commands based on the hci_conn state which has been possible without holding the hci_dev lock. The recent changes to do LE scanning before connect attempts added even more operations to hci_conn and hci_dev from hci_conn_timeout, thereby exposing potential race conditions with the hci_dev and hci_conn states. As an example of such a race, here there's a timeout but an l2cap_sock_connect() call manages to race with the cleanup routine: [Oct21 08:14] l2cap_chan_timeout: chan ee4b12c0 state BT_CONNECT [ +0.000004] l2cap_chan_close: chan ee4b12c0 state BT_CONNECT [ +0.000002] l2cap_chan_del: chan ee4b12c0, conn f3141580, err 111, state BT_CONNECT [ +0.000002] l2cap_sock_teardown_cb: chan ee4b12c0 state BT_CONNECT [ +0.000005] l2cap_chan_put: chan ee4b12c0 orig refcnt 4 [ +0.000010] hci_conn_drop: hcon f53d56e0 orig refcnt 1 [ +0.000013] l2cap_chan_put: chan ee4b12c0 orig refcnt 3 [ +0.000063] hci_conn_timeout: hcon f53d56e0 state BT_CONNECT [ +0.000049] hci_conn_params_del: addr ee:0d:30:09:53:1f (type 1) [ +0.000002] hci_chan_list_flush: hcon f53d56e0 [ +0.000001] hci_chan_del: hci0 hcon f53d56e0 chan f4e7ccc0 [ +0.004528] l2cap_sock_create: sock e708fc00 [ +0.000023] l2cap_chan_create: chan ee4b1770 [ +0.000001] l2cap_chan_hold: chan ee4b1770 orig refcnt 1 [ +0.000002] l2cap_sock_init: sk ee4b3390 [ +0.000029] l2cap_sock_bind: sk ee4b3390 [ +0.000010] l2cap_sock_setsockopt: sk ee4b3390 [ +0.000037] l2cap_sock_connect: sk ee4b3390 [ +0.000002] l2cap_chan_connect: 00:02:72:d9:e5:8b -> ee:0d:30:09:53:1f (type 2) psm 0x00 [ +0.000002] hci_get_route: 00:02:72:d9:e5:8b -> ee:0d:30:09:53:1f [ +0.000001] hci_dev_hold: hci0 orig refcnt 8 [ +0.000003] hci_conn_hold: hcon f53d56e0 orig refcnt 0 Above the l2cap_chan_connect() shouldn't have been able to reach the hci_conn f53d56e0 anymore but since hci_conn_timeout didn't do proper locking that's not the case. The end result is a reference to hci_conn that's not in the conn_hash list, resulting in list corruption when trying to remove it later: [Oct21 08:15] l2cap_chan_timeout: chan ee4b1770 state BT_CONNECT [ +0.000004] l2cap_chan_close: chan ee4b1770 state BT_CONNECT [ +0.000003] l2cap_chan_del: chan ee4b1770, conn f3141580, err 111, state BT_CONNECT [ +0.000001] l2cap_sock_teardown_cb: chan ee4b1770 state BT_CONNECT [ +0.000005] l2cap_chan_put: chan ee4b1770 orig refcnt 4 [ +0.000002] hci_conn_drop: hcon f53d56e0 orig refcnt 1 [ +0.000015] l2cap_chan_put: chan ee4b1770 orig refcnt 3 [ +0.000038] hci_conn_timeout: hcon f53d56e0 state BT_CONNECT [ +0.000003] hci_chan_list_flush: hcon f53d56e0 [ +0.000002] hci_conn_hash_del: hci0 hcon f53d56e0 [ +0.000001] ------------[ cut here ]------------ [ +0.000461] WARNING: CPU: 0 PID: 1782 at lib/list_debug.c:56 __list_del_entry+0x3f/0x71() [ +0.000839] list_del corruption, f53d56e0->prev is LIST_POISON2 (00000200) The necessary fix is unfortunately more complicated than just adding hci_dev_lock/unlock calls to the hci_conn_timeout() call path. Particularly, the hci_conn_del() API, which expects the hci_dev lock to be held, performs a cancel_delayed_work_sync(&hcon->disc_work) which would lead to a deadlock if the hci_conn_timeout() call path tries to acquire the same lock. This patch solves the problem by deferring the cleanup work to a separate work callback. To protect against the hci_dev or hci_conn going away meanwhile temporary references are taken with the help of hci_dev_hold() and hci_conn_get(). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # 4.3
|
#
5157b8a5 |
|
16-Oct-2015 |
Jakub Pawlowski <jpawlowski@google.com> |
Bluetooth: Fix initializing conn_params in scan phase This patch makes sure that conn_params that were created just for explicit_connect, will get properly deleted during cleanup. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Acked-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
9ad3e6ff |
|
16-Oct-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix conn_params list update in hci_connect_le_scan_cleanup After clearing the params->explicit_connect variable the parameters may need to be either added back to the right list or potentially left absent from both the le_reports and the le_conns lists. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
49c50922 |
|
16-Oct-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix LE reconnection logic We can't use hci_explicit_connect_lookup() since that would only cover explicit connections, leaving normal reconnections completely untouched. Not using it in turn means leaving out entries in pend_le_reports. To fix this and simplify the logic move conn params from the reports list to the pend_le_conns list for the duration of an explicit connect. Once the connect is complete move the params back to the pend_le_reports list. This also means that the explicit connect lookup function only needs to look into the pend_le_conns list. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
b958f9a3 |
|
16-Oct-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix reference counting for LE-scan based connections The code should never directly call hci_conn_hash_del since many cleanup & reference counting updates would be lost. Normally hci_conn_del is the right thing to do, but in the case of a connection doing LE scanning this could cause a deadlock due to doing a cancel_delayed_work_sync() on the same work callback that we were called from. Connections in the LE scanning state actually need very little cleanup - just a small subset of hci_conn_del. To solve the issue, refactor out these essential pieces into a new hci_conn_cleanup() function and call that from the two necessary places. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
168b8a25 |
|
16-Oct-2015 |
Jakub Pawlowski <jpawlowski@google.com> |
Bluetooth: Fix double scan updates When disable/enable scan command is issued twice, some controllers will return an error for the second request, i.e. requests with this command will fail on some controllers, and succeed on others. This patch makes sure that unnecessary scan disable/enable commands are not issued. When adding device to the auto connect whitelist when there is pending connect attempt, there is no need to update scan. hci_connect_le_scan_cleanup is conditionally executing hci_conn_params_del, that is calling hci_update_background_scan. Make the other case also update scan, and remove reduntand call from hci_connect_le_scan_remove. When stopping interleaved discovery the state should be set to stopped only when both LE scanning and discovery has stopped. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Acked-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
cc2b6911 |
|
07-Aug-2015 |
Jakub Pawlowski <jpawlowski@google.com> |
Bluetooth: timeout handling in new connect procedure Currently, when trying to connect to already paired device that just rotated its RPA MAC address, old address would be used and connection would fail. In order to fix that, kernel must scan and receive advertisement with fresh RPA before connecting. This patch makes sure that when new procedure is in use, and we're stuck in scan phase because no advertisement was received and timeout happened, or app decided to close socket, scan whitelist gets properly cleaned up. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
28a667c9 |
|
07-Aug-2015 |
Jakub Pawlowski <jpawlowski@google.com> |
Bluetooth: advertisement handling in new connect procedure Currently, when trying to connect to already paired device that just rotated its RPA MAC address, old address would be used and connection would fail. In order to fix that, kernel must scan and receive advertisement with fresh RPA before connecting. This path makes sure that after advertisement is received from device that we try to connect to, it is properly handled in check_pending_le_conn and trigger connect attempt. It also modifies hci_le_connect to make sure that connect attempt will be properly continued. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
f75113a2 |
|
07-Aug-2015 |
Jakub Pawlowski <jpawlowski@google.com> |
Bluetooth: add hci_connect_le_scan Currently, when trying to connect to already paired device that just rotated its RPA MAC address, old address would be used and connection would fail. In order to fix that, kernel must scan and receive advertisement with fresh RPA before connecting. This patch adds hci_connect_le_scan with dependencies, new method that will be used to connect to remote LE devices. Instead of just sending connect request, it adds a device to whitelist. Later patches will make use of this whitelist to send conenct request when advertisement is received, and properly handle timeouts. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
e7d9ab73 |
|
07-Aug-2015 |
Jakub Pawlowski <jpawlowski@google.com> |
Bluetooth: add hci_lookup_le_connect This patch adds hci_lookup_le_connect method, that will be used to check wether outgoing le connection attempt is in progress. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
8b76ce34 |
|
08-Jun-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix encryption key size handling for LTKs The encryption key size for LTKs is supposed to be applied only at the moment of encryption. When generating a Link Key (using LE SC) from the LTK the full non-shortened value should be used. This patch modifies the code to always keep the full value around and only apply the key size when passing the value to HCI. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
a358dc11 |
|
13-Mar-2015 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Introduce hci_dev_clear_flag helper macro Instead of manually coding clear_bit on hdev->dev_flags all the time, use hci_dev_clear_flag helper macro. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
a1536da2 |
|
13-Mar-2015 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Introduce hci_dev_set_flag helper macro Instead of manually coding set_bit on hdev->dev_flags all the time, use hci_dev_set_flag helper macro. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
d7a5a11d |
|
13-Mar-2015 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Introduce hci_dev_test_flag helper macro Instead of manually coding test_bit on hdev->dev_flags all the time, use hci_dev_test_flag helper macro. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
3a6d576b |
|
18-Feb-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Convert disconn_cfm to be triggered through hci_cb This patch moves all the disconn_cfm callbacks to be based on the hci_cb list. This means making l2cap_disconn_cfm private to l2cap_core.c and sco_conn_cb private to sco.c respectively. Since the hci_conn type filtering isn't done any more on the wrapper level the callbacks themselves need to check that they were passed a relevant type of connection. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
539c496d |
|
18-Feb-2015 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Convert connect_cfm to be triggered through hci_cb This patch moves all the connect_cfm callbacks to be based on the hci_cb list. This means making l2cap_connect_cfm private to l2cap_core.c and sco_connect_cb private to sco.c respectively. Since the hci_conn type filtering isn't done any more on the wrapper level the callbacks themselves need to check that they were passed a relevant type of connection. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
c411110e |
|
10-Feb-2015 |
Lukasz Rymanowski <lukasz.rymanowski@tieto.com> |
Bluetooth: Improve error handling in connect acl With this patch -EOPNOTSUPP will be returned by hci_connect_acl for LE only controllers. If it is dual device with disabled BREDR -ECONNREFUSED will be returned Signed-off-by: Lukasz Rymanowski <lukasz.rymanowski@tieto.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
152d386e |
|
10-Feb-2015 |
Lukasz Rymanowski <lukasz.rymanowski@tieto.com> |
Bluetooth: Do not allow LE connection if LE is not enabled Kernel gives possibility to enable/disable LE host support. There is flag HCI_LE_ENABLED which is set when this support is enabled and some parts of the code checks this flag e.g. SMP However it is still possible to make LE connection if LE Host support is disabled, what might be confused for remote device. This patch makes sure that kernel will not send HCI LE Create Connection if LE HOST support is not enabled. Signed-off-by: Lukasz Rymanowski <lukasz.rymanowski@tieto.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
0026b655 |
|
04-Jan-2015 |
Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> |
Bluetooth: Remove unused function Remove the function hci_conn_change_link_key() that is not used anywhere. This was partially found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
1904a853 |
|
11-Jan-2015 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Add opcode parameter to hci_req_complete_t callback When hci_req_run() calls its provided complete function and one of the HCI commands in the sequence fails, then provide the opcode of failing command. In case of success HCI_OP_NOP is provided since all commands completed. This patch fixes the prototype of hci_req_complete_t and all its users. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
23b9ceb7 |
|
20-Dec-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Create debugfs directory for each connection handle For every internal representation of a Bluetooth connection which is identified by hci_conn, create a debugfs directory with the handle number as directory name. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
0857dd3b |
|
19-Dec-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Split hci_request helpers to hci_request.[ch] None of the hci_request related things in net/bluetooth/hci_core.h are needed anywhere outside of the core bluetooth module. This patch creates a new net/bluetooth/hci_request.c file with its corresponding h-file and moves the functionality there from hci_core.c and hci_core.h. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
9437d2ed |
|
07-Dec-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Fix generation of non-resolvable private addresses When the host decides to use a non-resolvable private address, it must ensure that this generated address does not match the public address of the controller. Add an extra check to ensure this required behavior. In addition rename the variable from urpa to nrpa and fix all of the comments in the code that use the term unresolvable instead of the term non-resolvable as used in the Bluetooth specification. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
ebf86aa3 |
|
05-Dec-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix initializing hci_conn RSSI to invalid value When we create the hci_conn object we should properly initialize the RSSI to HCI_RSSI_INVALID. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
0b1db38c |
|
28-Oct-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix check for direct advertising These days we allow simultaneous LE scanning and advertising. Checking for whether advertising is enabled or not is therefore not a reliable way to determine whether directed advertising was used to trigger the connection creation. The appropriate place to check (instead of the hdev context) is the connection role that's stored in the hci_conn. This patch fixes such a check in le_conn_timeout() which could otherwise lead to incorrect HCI commands being sent. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # 3.16.x
|
#
980ffc0a |
|
28-Oct-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix LE connection timeout deadlock The le_conn_timeout() may call hci_le_conn_failed() which in turn may call hci_conn_del(). Trying to use the _sync variant for cancelling the conn timeout from hci_conn_del() could therefore result in a deadlock. This patch converts hci_conn_del() to use the non-sync variant so the deadlock is not possible. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org # 3.16.x
|
#
4f639ede |
|
25-Oct-2014 |
Fabian Frederick <fabf@skynet.be> |
Bluetooth: fix shadow warning in hci_disconnect() use clkoff_cp for hci_cp_read_clock_offset instead of cp (already defined above). Suggested-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
89cbb063 |
|
11-Oct-2014 |
Alfonso Acosta <fons@spotify.com> |
Bluetooth: Defer connection-parameter removal when unpairing Systematically removing the LE connection parameters and autoconnect action is inconvenient for rebonding without disconnecting from userland (i.e. unpairing followed by repairing without disconnecting). The parameters will be lost after unparing and userland needs to take care of book-keeping them and re-adding them. This patch allows userland to forget about parameter management when rebonding without disconnecting. It defers clearing the connection parameters when unparing without disconnecting, giving a chance of keeping the parameters if a repairing happens before the connection is closed. Signed-off-by: Alfonso Acosta <fons@spotify.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
565766b0 |
|
25-Sep-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Rename sco_param_wideband table to esco_param_msbc The sco_param_wideband table represents the eSCO parameters for specifically mSBC encoding. This patch renames the table to the more descriptive esco_param_msbc name. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
c7da5797 |
|
24-Sep-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Add retransmission effort into SCO parameter table It is expected that new parameter combinations will have the retransmission effort value different between some entries (mainly because of the new S4 configuration added by HFP 1.7), so it makes sense to move it into the table instead of having it hard coded based on the selected SCO_AIRMODE_*. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
d41c15cf |
|
24-Sep-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix reason code used for rejecting SCO connections The core specification defines valid values for the HCI_Reject_Synchronous_Connection_Request command to be 0x0D-0x0F. So far the code has been using HCI_ERROR_REMOTE_USER_TERM (0x13) which is not a valid value and is therefore being rejected by some controllers: > HCI Event: Connect Request (0x04) plen 10 bdaddr 40:6F:2A:6A:E5:E0 class 0x000000 type eSCO < HCI Command: Reject Synchronous Connection (0x01|0x002a) plen 7 bdaddr 40:6F:2A:6A:E5:E0 reason 0x13 Reason: Remote User Terminated Connection > HCI Event: Command Status (0x0f) plen 4 Reject Synchronous Connection (0x01|0x002a) status 0x12 ncmd 1 Error: Invalid HCI Command Parameters This patch introduces a new define for a value from the valid range (0x0d == Connection Rejected Due To Limited Resources) and uses it instead for rejecting incoming connections. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
48e68ff5 |
|
23-Sep-2014 |
Bernhard Thaler <bernhard.thaler@r-it.at> |
Bluetooth: Check for SCO type before setting retransmission effort SCO connection cannot be setup to devices that do not support retransmission. Patch based on http://permalink.gmane.org/gmane.linux.bluez.kernel/7779 and adapted for this kernel version. Code changed to check SCO/eSCO type before setting retransmission effort and max. latency. The purpose of the patch is to support older devices not capable of eSCO. Tested on Blackberry 655+ headset which does not support retransmission. Credits go to Alexander Sommerhuber. Signed-off-by: Bernhard Thaler <bernhard.thaler@r-it.at> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
839035a7 |
|
18-Aug-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Move clock offset reading into hci_disconnect() To give all hci_disconnect() users the advantage of getting the clock offset read automatically this patch moves the necessary code from hci_conn_timeout() into hci_disconnect(). This way we pretty much always update the clock offset when disconnecting. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
e3b679d5 |
|
18-Aug-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Update hci_disconnect() to return an error value We'll soon use hci_disconnect() from places that are interested to know whether the hci_send_cmd() really succeeded or not. This patch updates hci_disconnect() to pass on any error returned from hci_send_cmd(). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
bcbb655a |
|
18-Aug-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Remove hci_conn_hold/drop from hci_chan We can't have hci_chan contribute to the "active" reference counting of the hci_conn since otherwise the connection would never get dropped when there are no more users (since hci_chan would be counted as a user). This patch removes hold() when creating the hci_chan and drop() when destroying it. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
f94b665d |
|
17-Aug-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Ignore incoming data after initiating disconnection When hci_chan_del is called the disconnection routines get scheduled through a workqueue. If there's any incoming ACL data before the routines get executed there's a chance that a new hci_chan is created and the disconnection never happens. This patch adds a new hci_conn flag to indicate that we're in the process of driving the connection down. We set the flag in hci_chan_del and check for it in hci_chan_create so that no new channels are created for the same connection. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
b3ff670a |
|
17-Aug-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Set disc_timeout to 0 when calling hci_chan_del The hci_chan_del() function is used in scenarios where we've decided we want to get rid of the underlying baseband link. It makes therefore sense to force the disc_timeout to 0 so that the disconnection routines are immediately scheduled. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
6c388d32 |
|
17-Aug-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix hci_conn reference counting with hci_chan The hci_chan_del() function was doing a hci_conn_drop() but there was no matching hci_conn_hold() in the hci_chan_create() function. Furthermore, as the hci_chan struct holds a pointer to the hci_conn there should be proper use of hci_conn_get/put. This patch fixes both issues so that hci_chan does correct reference counting of the hci_conn object. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
f8aaf9b6 |
|
17-Aug-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix using hci_conn_get() for hci_conn pointers Wherever we keep hci_conn pointers around we should be using hci_conn_get/put to ensure that they stay valid. This patch fixes all places violating against the principle currently. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
f161dd41 |
|
15-Aug-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix hci_conn reference counting for auto-connections Recently the LE passive scanning and auto-connections feature was introduced. It uses the hci_connect_le() API which returns a hci_conn along with a reference count to that object. All previous users would tie this returned reference to some existing object, such as an L2CAP channel, and there'd be no leaked references this way. For auto-connections however the reference was returned but not stored anywhere, leaving established connections with one higher reference count than they should have. Instead of playing special tricks with hci_conn_hold/drop this patch associates the returned reference from hci_connect_le() with the object that in practice does own this reference, i.e. the hci_conn_params struct that caused us to initiate a connection in the first place. Once the connection is established or fails to establish this reference is removed appropriately. One extra thing needed is to call hci_pend_le_actions_clear() before calling hci_conn_hash_flush() so that the reference is cleared before the hci_conn objects are fully removed. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
27f70f3e |
|
21-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Prefer sizeof(*ptr) when allocating memory It's safer practice to use sizeof(*ptr) instead of sizeof(ptr_type) when allocating memory in case the type changes. This also fixes the following style of warnings from static analyzers: CHECK: Prefer kzalloc(sizeof(*ie)...) over kzalloc(sizeof(struct inquiry_entry)...) + ie = kzalloc(sizeof(struct inquiry_entry), GFP_KERNEL); Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
beb19e4c |
|
18-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Use EOPNOTSUPP instead of ENOTSUPP The EOPNOTSUPP and ENOTSUPP errors are very similar in meaning, but ENOTSUPP is a fairly new addition to POSIX. Not all libc versions know about the value the kernel uses for ENOTSUPP so it's better to use EOPNOTSUPP to ensure understandable error messages. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
977f8fce |
|
17-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Introduce a flag to track who really initiates authentication Even though our side requests authentication, the original action that caused it may be remotely triggered, such as an incoming L2CAP or RFCOMM connect request. To track this information introduce a new hci_conn flag called HCI_CONN_AUTH_INITIATOR. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
e7cafc45 |
|
17-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Pass initiator/acceptor information to hci_conn_security() We're interested in whether an authentication request is because of a remote or local action. So far hci_conn_security() has been used both for incoming and outgoing actions (e.g. RFCOMM or L2CAP connect requests) so without some modifications it cannot know which peer is responsible for requesting authentication. This patch adds a new "bool initiator" parameter to hci_conn_security() to indicate which side is responsible for the request and updates the current users to pass this information correspondingly. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
a5c4e309 |
|
16-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Add a role parameter to hci_conn_add() We need to be able to track slave vs master LE connections in hci_conn_hash, and to be able to do that we need to know the role of the connection by the time hci_conn_add_has() is called. This means in practice the hci_conn_add() call that creates the hci_conn_object. This patch adds a new role parameter to hci_conn_add() function to give the object its initial role value, and updates the callers to pass the appropriate role to it. Since the function now takes care of initializing both conn->role and conn->out values we can remove some other unnecessary assignments. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
e804d25d |
|
16-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Use explicit role instead of a bool in function parameters To make the code more understandable it makes sense to use the new HCI defines for connection role instead of a "bool master" parameter. This makes it immediately clear when looking at the function calls what the last parameter is describing. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
40bef302 |
|
16-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Convert HCI_CONN_MASTER flag to a conn->role variable Having a dedicated u8 role variable in the hci_conn struct greatly simplifies tracking of the role, since this is the native way that it's represented on the HCI level. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
e8bb6b97 |
|
08-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix advertising and active scanning co-existence Many controllers allow simultaneous active scanning and advertising (e.g. Intel and Broadcom) but some do not (e.g. CSR). It's therefore safest to implement mutual exclusion of these states in the kernel. This patch ensures that the two states are never entered simultaneously. Extra precaution needs to be taken for outgoing connection attempts in slave role (i.e. through directed advertising) in which case the operation that came first has precedence and the one that comes after gets a rejection. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
376f54c1 |
|
08-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Stop advertising always before initiating a connection Most controllers do not support advertising while initiating an LE connection. We also have to first disable current advertising if the initiation is going to happen through direct advertising. Therefore, simply stop advertising as the first thing when starting to issue commands to establish an LE connection. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
5ce194c4 |
|
08-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Use real advertising state to random address update decision Now that we have a flag for tracking the real advertising state we should use that to determine whether it's safe to update the random address or not. The couple of places that were clearing the flag due to a pending request need to be updated too. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
cdd6275e |
|
07-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Pass desired connection role to hci_connect_le() If we have both LE scanning and advertising simultaneously enabled we need a way to tell hci_connect_le() in which role to initiate a connection. This patch adds a new parameter to the function to give it the necessary information. For auto-connect and mgmt_pair_device we always use master role, whereas for L2CAP users (in practice sockets) we use slave role whenever HCI_ADVERTISING is set and master role otherwise. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
d93375a8 |
|
07-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Remove auth_type parameter from hci_connect_le() The auth_type value which gets assigned to hci_conn->auth_type is something that's only used for BR/EDR connections and is of no value for LE connections. It makes therefore little sense to pass it to the hci_connect_le() function. This patch removes the parameter from the function. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
09ae260b |
|
06-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Use lower timeout for LE auto-connections When we establish connections as a consequence of receiving an advertising report it makes no sense to wait the normal 20 second LE connection timeout. This patch modifies the hci_connect_le function to take an extra timeout value and uses a lower 2 second timeout for the auto-connection case. This timeout is intentionally chosen to be just a bit higher than the 1.28 second timeout that High Duty Cycle Advertising uses. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
7d6ca693 |
|
02-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Make hci_le_conn_update return the store hint The caller of hci_le_conn_update is directly interested in knowing what the best value is for the store_hint parameter of the corresponding mgmt event. Since hci_le_conn_update knows whether there were stored parameters that were updated or not we can have it return an initial store_hint value to the caller. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
04fb7d90 |
|
29-Jun-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Provide defaults for LE connection latency and timeout Store the connection latency and supervision timeout default values with all the other controller defaults. And when needed use them for new connections. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
037fc415 |
|
29-Jun-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Use LE connection parameters if known When the LE connection parameters for connection latency and supervision timeout are known, then use then. If they are not know fallback to defaults. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
f044eb05 |
|
29-Jun-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Store latency and supervision timeout in connection params When the slave updates the connection parameters, store also the connection latency and supervision timeout information in the internal list of connection parameters for known devices. Having these values available allowes the auto-connection procedure to use the correct values from the beginning without having to request an update on every connection establishment. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
fee746b0 |
|
28-Jun-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Restrict access for raw-only controllers Bluetooth controllers that are marked for raw-only usage can only be used with user channel access. Any other operation should be rejected. This simplifies the whole raw-only support since it now depends on the fact that the controller is marked with HCI_QUIRK_RAW_DEVICE and runtime raw access is restricted to user channel operation. The kernel internal processing of HCI commands and events is designed around the case that either the kernel has full control over the device or that the device is driven from userspace. This now makes a clear distinction between these two possible operation modes. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
df935429 |
|
27-Jun-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Send HCI_Read_Clock_Offset before disconnecting When the connection is in master role and it is going to be disconnected based on the disconnection timeout, then send the HCI_Read_Clock_Offset command in an attempt to update the clock offset value in the inquiry cache. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
40051e46 |
|
27-Jun-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Remove unneeded hci_conn_disconnect abstraction The abstraction of disconnect operation via hci_conn_disconnect is not needed and it does not add any readability. Handle the difference of AMP physical channels and BR/EDR/LE connection in the timeout callback. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
a2b1976b |
|
27-Jun-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Remove reason parameter from hci_amp_disconn function The hci_amp_disconn function is a local function and there is no need for a reason parameter. That one can be retrieved from the hci_conn object easily. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
4dae2798 |
|
24-Jun-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Convert hci_conn->link_mode into flags Since the link_mode member of the hci_conn struct is a bit field and we already have a flags member as well it makes sense to merge these two together. This patch moves all used link_mode bits into corresponding flags. To keep backwards compatibility with user space we still need to provide a get_link_mode() helper function for the ioctl's that expect a link_mode style value. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
1d56dc4f |
|
17-Jun-2014 |
Lukasz Rymanowski <lukasz.rymanowski@tieto.com> |
Bluetooth: Fix for ACL disconnect when pairing fails When pairing fails hci_conn refcnt drops below zero. This cause that ACL link is not disconnected when disconnect timeout fires. Probably this is because l2cap_conn_del calls l2cap_chan_del for each channel, and inside l2cap_chan_del conn is dropped. After that loop hci_chan_del is called which also drops conn. Anyway, as it is desrcibed in hci_core.h, it is known that refcnt drops below 0 sometimes and it should be fine. If so, let disconnect link when hci_conn_timeout fires and refcnt is 0 or below. This patch does it. This affects PTS test SM_TC_JW_BV_05_C Logs from scenario: [69713.706227] [6515] pair_device: [69713.706230] [6515] hci_conn_add: hci0 dst 00:1b:dc:06:06:22 [69713.706233] [6515] hci_dev_hold: hci0 orig refcnt 8 [69713.706235] [6515] hci_conn_init_sysfs: conn ffff88021f65a000 [69713.706239] [6515] hci_req_add_ev: hci0 opcode 0x200d plen 25 [69713.706242] [6515] hci_prepare_cmd: skb len 28 [69713.706243] [6515] hci_req_run: length 1 [69713.706248] [6515] hci_conn_hold: hcon ffff88021f65a000 orig refcnt 0 [69713.706251] [6515] hci_dev_put: hci0 orig refcnt 9 [69713.706281] [8909] hci_cmd_work: hci0 cmd_cnt 1 cmd queued 1 [69713.706288] [8909] hci_send_frame: hci0 type 1 len 28 [69713.706290] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 28 [69713.706316] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000 [69713.706382] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000 [69713.711664] [8909] hci_rx_work: hci0 [69713.711668] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 6 [69713.711680] [8909] hci_rx_work: hci0 Event packet [69713.711683] [8909] hci_cs_le_create_conn: hci0 status 0x00 [69713.711685] [8909] hci_sent_cmd_data: hci0 opcode 0x200d [69713.711688] [8909] hci_req_cmd_complete: opcode 0x200d status 0x00 [69713.711690] [8909] hci_sent_cmd_data: hci0 opcode 0x200d [69713.711695] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000 [69713.711744] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000 [69713.818875] [8909] hci_rx_work: hci0 [69713.818889] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 21 [69713.818913] [8909] hci_rx_work: hci0 Event packet [69713.818917] [8909] hci_le_conn_complete_evt: hci0 status 0x00 [69713.818922] [8909] hci_send_to_control: len 19 [69713.818927] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000 [69713.818938] [8909] hci_conn_add_sysfs: conn ffff88021f65a000 [69713.818975] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800 [69713.818981] [6515] hci_sock_recvmsg: sock ffff88005e75a080, sk ffff88010323ac00 ... [69713.819021] [8909] hci_dev_hold: hci0 orig refcnt 10 [69713.819025] [8909] l2cap_connect_cfm: hcon ffff88021f65a000 bdaddr 00:1b:dc:06:06:22 status 0 [69713.819028] [8909] hci_chan_create: hci0 hcon ffff88021f65a000 [69713.819031] [8909] l2cap_conn_add: hcon ffff88021f65a000 conn ffff880221005c00 hchan ffff88020d60b1c0 [69713.819034] [8909] l2cap_conn_ready: conn ffff880221005c00 [69713.819036] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000 [69713.819037] [8909] smp_conn_security: conn ffff880221005c00 hcon ffff88021f65a000 level 0x02 [69713.819039] [8909] smp_chan_create: [69713.819041] [8909] hci_conn_hold: hcon ffff88021f65a000 orig refcnt 1 [69713.819043] [8909] smp_send_cmd: code 0x01 [69713.819045] [8909] hci_send_acl: hci0 chan ffff88020d60b1c0 flags 0x0000 [69713.819046] [5949] hci_sock_recvmsg: sock ffff8800941a9900, sk ffff88012bf4e800 [69713.819049] [8909] hci_queue_acl: hci0 nonfrag skb ffff88005157c100 len 15 [69713.819055] [5949] hci_sock_recvmsg: sock ffff8800941a9900, sk ffff88012bf4e800 [69713.819057] [8909] l2cap_le_conn_ready: [69713.819064] [8909] l2cap_chan_create: chan ffff88005ede2c00 [69713.819066] [8909] l2cap_chan_hold: chan ffff88005ede2c00 orig refcnt 1 [69713.819069] [8909] l2cap_sock_init: sk ffff88005ede5800 [69713.819072] [8909] bt_accept_enqueue: parent ffff880160356000, sk ffff88005ede5800 [69713.819074] [8909] __l2cap_chan_add: conn ffff880221005c00, psm 0x00, dcid 0x0004 [69713.819076] [8909] l2cap_chan_hold: chan ffff88005ede2c00 orig refcnt 2 [69713.819078] [8909] hci_conn_hold: hcon ffff88021f65a000 orig refcnt 2 [69713.819080] [8909] smp_conn_security: conn ffff880221005c00 hcon ffff88021f65a000 level 0x01 [69713.819082] [8909] l2cap_sock_ready_cb: sk ffff88005ede5800, parent ffff880160356000 [69713.819086] [8909] le_pairing_complete_cb: status 0 [69713.819091] [8909] hci_tx_work: hci0 acl 10 sco 8 le 0 [69713.819093] [8909] hci_sched_acl: hci0 [69713.819094] [8909] hci_sched_sco: hci0 [69713.819096] [8909] hci_sched_esco: hci0 [69713.819098] [8909] hci_sched_le: hci0 [69713.819099] [8909] hci_chan_sent: hci0 [69713.819101] [8909] hci_chan_sent: chan ffff88020d60b1c0 quote 10 [69713.819104] [8909] hci_sched_le: chan ffff88020d60b1c0 skb ffff88005157c100 len 15 priority 7 [69713.819106] [8909] hci_send_frame: hci0 type 2 len 15 [69713.819108] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 15 [69713.819119] [8909] hci_chan_sent: hci0 [69713.819121] [8909] hci_prio_recalculate: hci0 [69713.819123] [8909] process_pending_rx: [69713.819226] [6450] hci_sock_recvmsg: sock ffff88005e758780, sk ffff88010323d400 ... [69713.822022] [6450] l2cap_sock_accept: sk ffff880160356000 timeo 0 [69713.822024] [6450] bt_accept_dequeue: parent ffff880160356000 [69713.822026] [6450] bt_accept_unlink: sk ffff88005ede5800 state 1 [69713.822028] [6450] l2cap_sock_accept: new socket ffff88005ede5800 [69713.822368] [6450] l2cap_sock_getname: sock ffff8800941ab700, sk ffff88005ede5800 [69713.822375] [6450] l2cap_sock_getsockopt: sk ffff88005ede5800 [69713.822383] [6450] l2cap_sock_getname: sock ffff8800941ab700, sk ffff88005ede5800 [69713.822414] [6450] bt_sock_poll: sock ffff8800941ab700, sk ffff88005ede5800 ... [69713.823255] [6450] l2cap_sock_getname: sock ffff8800941ab700, sk ffff88005ede5800 [69713.823259] [6450] l2cap_sock_getsockopt: sk ffff88005ede5800 [69713.824322] [6450] l2cap_sock_getname: sock ffff8800941ab700, sk ffff88005ede5800 [69713.824330] [6450] l2cap_sock_getsockopt: sk ffff88005ede5800 [69713.825029] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800 ... [69713.825187] [6450] l2cap_sock_sendmsg: sock ffff8800941ab700, sk ffff88005ede5800 [69713.825189] [6450] bt_sock_wait_ready: sk ffff88005ede5800 [69713.825192] [6450] l2cap_create_basic_pdu: chan ffff88005ede2c00 len 3 [69713.825196] [6450] l2cap_do_send: chan ffff88005ede2c00, skb ffff880160b0b500 len 7 priority 0 [69713.825199] [6450] hci_send_acl: hci0 chan ffff88020d60b1c0 flags 0x0000 [69713.825201] [6450] hci_queue_acl: hci0 nonfrag skb ffff880160b0b500 len 11 [69713.825210] [8909] hci_tx_work: hci0 acl 9 sco 8 le 0 [69713.825213] [8909] hci_sched_acl: hci0 [69713.825214] [8909] hci_sched_sco: hci0 [69713.825216] [8909] hci_sched_esco: hci0 [69713.825217] [8909] hci_sched_le: hci0 [69713.825219] [8909] hci_chan_sent: hci0 [69713.825221] [8909] hci_chan_sent: chan ffff88020d60b1c0 quote 9 [69713.825223] [8909] hci_sched_le: chan ffff88020d60b1c0 skb ffff880160b0b500 len 11 priority 0 [69713.825225] [8909] hci_send_frame: hci0 type 2 len 11 [69713.825227] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 11 [69713.825242] [8909] hci_chan_sent: hci0 [69713.825253] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000 [69713.825253] [8909] hci_prio_recalculate: hci0 [69713.825292] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000 [69713.825768] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800 ... [69713.866902] [8909] hci_rx_work: hci0 [69713.866921] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 7 [69713.866928] [8909] hci_rx_work: hci0 Event packet [69713.866931] [8909] hci_num_comp_pkts_evt: hci0 num_hndl 1 [69713.866937] [8909] hci_tx_work: hci0 acl 9 sco 8 le 0 [69713.866939] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000 [69713.866940] [8909] hci_sched_acl: hci0 ... [69713.866944] [8909] hci_sched_le: hci0 [69713.866953] [8909] hci_chan_sent: hci0 [69713.866997] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000 [69713.867840] [28074] hci_rx_work: hci0 [69713.867844] [28074] hci_send_to_monitor: hdev ffff88021f0c7000 len 7 [69713.867850] [28074] hci_rx_work: hci0 Event packet [69713.867853] [28074] hci_num_comp_pkts_evt: hci0 num_hndl 1 [69713.867857] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000 [69713.867858] [28074] hci_tx_work: hci0 acl 10 sco 8 le 0 [69713.867860] [28074] hci_sched_acl: hci0 [69713.867861] [28074] hci_sched_sco: hci0 [69713.867862] [28074] hci_sched_esco: hci0 [69713.867863] [28074] hci_sched_le: hci0 [69713.867865] [28074] hci_chan_sent: hci0 [69713.867888] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000 [69714.145661] [8909] hci_rx_work: hci0 [69714.145666] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 10 [69714.145676] [8909] hci_rx_work: hci0 ACL data packet [69714.145679] [8909] hci_acldata_packet: hci0 len 6 handle 0x002d flags 0x0002 [69714.145681] [8909] hci_conn_enter_active_mode: hcon ffff88021f65a000 mode 0 [69714.145683] [8909] l2cap_recv_acldata: conn ffff880221005c00 len 6 flags 0x2 [69714.145693] [8909] l2cap_recv_frame: len 2, cid 0x0006 [69714.145696] [8909] hci_send_to_control: len 14 [69714.145710] [8909] smp_chan_destroy: [69714.145713] [8909] pairing_complete: status 3 [69714.145714] [8909] cmd_complete: sock ffff88010323ac00 [69714.145717] [8909] hci_conn_drop: hcon ffff88021f65a000 orig refcnt 3 [69714.145719] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000 [69714.145720] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800 [69714.145722] [6515] hci_sock_recvmsg: sock ffff88005e75a080, sk ffff88010323ac00 [69714.145724] [6450] bt_sock_poll: sock ffff8801db6b4f00, sk ffff880160351c00 ... [69714.145735] [6515] hci_sock_recvmsg: sock ffff88005e75a080, sk ffff88010323ac00 [69714.145737] [8909] hci_conn_drop: hcon ffff88021f65a000 orig refcnt 2 [69714.145739] [8909] l2cap_conn_del: hcon ffff88021f65a000 conn ffff880221005c00, err 13 [69714.145740] [6450] bt_sock_poll: sock ffff8801db6b5400, sk ffff88021e775000 [69714.145743] [6450] bt_sock_poll: sock ffff8801db6b5e00, sk ffff880160356000 [69714.145744] [8909] l2cap_chan_hold: chan ffff88005ede2c00 orig refcnt 3 [69714.145746] [6450] bt_sock_poll: sock ffff8800941ab700, sk ffff88005ede5800 [69714.145748] [8909] l2cap_chan_del: chan ffff88005ede2c00, conn ffff880221005c00, err 13 [69714.145749] [8909] l2cap_chan_put: chan ffff88005ede2c00 orig refcnt 4 [69714.145751] [8909] hci_conn_drop: hcon ffff88021f65a000 orig refcnt 1 [69714.145754] [6450] bt_sock_poll: sock ffff8800941ab700, sk ffff88005ede5800 [69714.145756] [8909] l2cap_chan_put: chan ffff88005ede2c00 orig refcnt 3 [69714.145759] [8909] hci_chan_del: hci0 hcon ffff88021f65a000 chan ffff88020d60b1c0 [69714.145766] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000 [69714.145787] [6515] hci_sock_release: sock ffff88005e75a080 sk ffff88010323ac00 [69714.146002] [6450] hci_sock_recvmsg: sock ffff88005e758780, sk ffff88010323d400 [69714.150795] [6450] l2cap_sock_release: sock ffff8800941ab700, sk ffff88005ede5800 [69714.150799] [6450] l2cap_sock_shutdown: sock ffff8800941ab700, sk ffff88005ede5800 [69714.150802] [6450] l2cap_chan_close: chan ffff88005ede2c00 state BT_CLOSED [69714.150805] [6450] l2cap_sock_kill: sk ffff88005ede5800 state BT_CLOSED [69714.150806] [6450] l2cap_chan_put: chan ffff88005ede2c00 orig refcnt 2 [69714.150808] [6450] l2cap_sock_destruct: sk ffff88005ede5800 [69714.150809] [6450] l2cap_chan_put: chan ffff88005ede2c00 orig refcnt 1 [69714.150811] [6450] l2cap_chan_destroy: chan ffff88005ede2c00 [69714.150970] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800 ... [69714.151991] [8909] hci_conn_drop: hcon ffff88021f65a000 orig refcnt 0 [69716.150339] [8909] hci_conn_timeout: hcon ffff88021f65a000 state BT_CONNECTED, refcnt -1 Signed-off-by: Lukasz Rymanowski <lukasz.rymanowski@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
e694788d |
|
10-Jun-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix check for connection encryption The conn->link_key variable tracks the type of link key in use. It is set whenever we respond to a link key request as well as when we get a link key notification event. These two events do not however always guarantee that encryption is enabled: getting a link key request and responding to it may only mean that the remote side has requested authentication but not encryption. On the other hand, the encrypt change event is a certain guarantee that encryption is enabled. The real encryption state is already tracked in the conn->link_mode variable through the HCI_LM_ENCRYPT bit. This patch fixes a check for encryption in the hci_conn_auth function to use the proper conn->link_mode value and thereby eliminates the chance of a false positive result. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org
|
#
b62b6505 |
|
04-Jun-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix incorrectly overriding conn->src_type The src_type member of struct hci_conn should always reflect the address type of the src_member. It should never be overridden. There is already code in place in the command status handler of HCI_LE_Create_Connection to copy the right initiator address into conn->init_addr_type. Without this patch, if privacy is enabled, we will send the wrong address type in the SMP identity address information PDU (it'll e.g. contain our public address but a random address type). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org
|
#
4bc58f51 |
|
20-May-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Make SMP context private to smp.c There are no users of the smp_chan struct outside of smp.c so move it away from smp.h. The addition of the l2cap.h include to hci_core.c, hci_conn.c and mgmt.c is something that should have been there already previously to avoid warnings of undeclared struct l2cap_conn, but the compiler warning was apparently shadowed away by the mention of l2cap_conn in the struct smp_chan definition. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
d0455ed9 |
|
14-May-2014 |
Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> |
Bluetooth: Store max TX power level for connection This patch adds support to store local maximum TX power level for connection when reply for HCI_Read_Transmit_Power_Level is received. Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
5a134fae |
|
09-May-2014 |
Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> |
Bluetooth: Store TX power level for connection This patch adds support to store local TX power level for connection when reply for HCI_Read_Transmit_Power_Level is received. Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
09da1f34 |
|
11-Apr-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix redundant encryption request for reauthentication When we're performing reauthentication (in order to elevate the security level from an unauthenticated key to an authenticated one) we do not need to issue any encryption command once authentication completes. Since the trigger for the encryption HCI command is the ENCRYPT_PEND flag this flag should not be set in this scenario. Instead, the REAUTH_PEND flag takes care of all necessary steps for reauthentication. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org
|
#
3c857757 |
|
25-Mar-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Add directed advertising support through connect() When we're in peripheral mode (HCI_ADVERTISING flag is set) the most natural mapping of connect() is to perform directed advertising to the peer device. This patch does the necessary changes to enable directed advertising and keeps the hci_conn state as BT_CONNECT in a similar way as is done for central or BR/EDR connection initiation. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
9c84d1da |
|
24-Mar-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Move local identity address setting to a central place Any time hci_conn_add is used for an LE connection we need to ensure that the local identity address is correctly described in the src and src_type variables. This patch moves setting these values directly into hci_conn_add so that callers don't have to duplicate the effort themselves. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
40b552aa |
|
19-Mar-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Enforce strict Secure Connections Only mode security In Secure Connections Only mode, it is required that Secure Connections is used for pairing and that the link key is encrypted with AES-CCM using a P-256 authenticated combination key. If this is not the case, then new connection shall be refused or existing connections shall be dropped. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
dcf4adbf |
|
12-Mar-2014 |
Joe Perches <joe@perches.com> |
Bluetooth: Convert uses of __constant_<foo> to <foo> The use of __constant_<foo> has been unnecessary for quite awhile now. Make these uses consistent with the rest of the kernel. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
81ad6fd9 |
|
28-Feb-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Remove unnecessary stop_scan_complete function The stop_scan_complete function was used as an intermediate step before doing the actual connection creation. Since we're using hci_request there's no reason to have this extra function around, i.e. we can simply put both HCI commands into the same request. The single task that the intermediate function had, i.e. indicating discovery as stopped is now taken care of by a new HCI_LE_SCAN_INTERRUPTED flag which allows us to do the discovery state update when the stop scan command completes. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
317ac8cb |
|
28-Feb-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix trying to disable scanning twice The discovery process has a timer for disabling scanning, however scanning might be disabled through other means too like the auto-connect process. We should therefore ensure that the timer is never active after sending a HCI command to disable scanning. There was some existing code in stop_scan_complete trying to avoid the timer when a connect request interrupts a discovery procedure, but the other way around was not covered. This patch covers both scenarios by canceling the timer as soon as we get a successful command complete for the disabling HCI command. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
9489eca4 |
|
28-Feb-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Add timeout for LE connection attempts LE connection attempts do not have a controller side timeout in the same way as BR/EDR has (in form of the page timeout). Since we always do scanning before initiating connections the attempts are always expected to succeed in some reasonable time. This patch adds a timer which forces a cancellation of the connection attempt within 20 seconds if it has not been successful by then. This way we e.g. ensure that mgmt_pair_device times out eventually and gives an error response. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
b46e0030 |
|
27-Feb-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix updating connection state to BT_CONNECT too early We shouldn't update the hci_conn state to BT_CONNECT until the moment that we're ready to send the initiating HCI command for it. If the connection has the BT_CONNECT state too early the code responsible for updating the local random address may incorrectly think there's a pending connection in progress and refuse to update the address. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
fe39c7b2 |
|
27-Feb-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Use __le64 type for LE random numbers The random numbers in Bluetooth Low Energy are 64-bit numbers and should also be little endian since the HCI specification is little endian. Change the whole Low Energy pairing to use __le64 instead of a byte array. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
a4790dbd |
|
26-Feb-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Introduce LE auto connection infrastructure 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 <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
6f77d8c7 |
|
26-Feb-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Move address type conversion to outside hci_connect_le 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 <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
04a6c589 |
|
26-Feb-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Refactor HCI connection code 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 <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
c99ed834 |
|
26-Feb-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Remove unused function This patch removes hci_create_le_conn() since it is not used anymore. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
2acf3d90 |
|
26-Feb-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Stop scanning on LE connection 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 <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
06c053fb |
|
26-Feb-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Declare le_conn_failed in hci_core.h 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 <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
94b1fc92 |
|
23-Feb-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Use unresolvable private address for active scanning 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 <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
e26b1ffa |
|
23-Feb-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix setting correct src_type when connecting LE 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 <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
85030be4 |
|
23-Feb-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Use hci_update_random_address() when connecting LE When we initiate LE connections we need to update the local random address if necessary. This patch updates the LE connection creation mechanism to use the new hci_update_random_address() function to set the own_address_type parameter and to update the local random address if necessary. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
d66c2950 |
|
18-Feb-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Use same LE min/max connection event length during update During LE connection establishment the value 0x0000 is used for min/max connection event length. So use the same value when the peripheral is requesting an update of the the connection paramters. For some reason the value 0x0001 got used in the connection update and 0x0000 in the connection creation. Using the same value for both just makes sense. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
edb4b466 |
|
18-Feb-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Fix wrong identity address during connection failures When the connection attempt fails, the address information are not provided in the HCI_LE_Connection_Complete event. So use the original information from the connection to reconstruct the identity address. This is important when a connection attempt has been made using the identity address, but the cached resolvable random address has changed in the meantime. The failure event needs to use the identity address and not the resolvable random address. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
1ebfcc1f |
|
18-Feb-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Look up RPA for connection requests with Identity Address We need to check whether there's a matching IRK and RPA when we're requested to connect to a remote LE device based on its Identity Address. This patch updates the hci_connect_le function to do an extra call to hci_find_irk_by_addr and uses the RPA if it's cached. This is particularly important once we start exposing the Identity Address to user space instead of the RPA in events such as Device Connected and Device Found. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
4292f1f3 |
|
03-Feb-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Use connection parameters if any This patch changes hci_connect_le() so it uses the connection parameters specified for the certain device. If no parameters were configured, we use the default values. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
9cb2e030 |
|
01-Feb-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Include security level 4 in connections check This check is only used for RFCOMM connections and most likely no RFCOMM based profile will require security level 4 secure connection security policy. In case it ever does make sure that seucrity level 4 is treated as sufficient security level. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
9bb3c01f |
|
30-Jan-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Introduce le_conn_failed() helper This patch moves connection attempt failure code to its own function so it can be reused in the next patch. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
1e406eef |
|
30-Jan-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Save connection interval parameters in hci_conn This patch creates two new fields in struct hci_conn to save the minimum and maximum connection interval values used to establish the connection this object represents. This change is required in order to know what parameters the connection is currently using. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
7b5a9241 |
|
15-Jan-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Introduce requirements for security level 4 The security level 4 is a new strong security requirement that is based around 128-bit equivalent strength for link and encryption keys required using FIPS approved algorithms. Which means that E0, SAFER+ and P-192 are not allowed. Only connections created with P-256 resulting from using Secure Connections support are allowed. This security level needs to be enforced when Secure Connection Only mode is enabled for a controller or a service requires FIPS compliant strong security. Currently it is not possible to enable either of these two cases. This patch just puts in the foundation for being able to handle security level 4 in the future. It should be noted that devices or services with security level 4 requirement can only communicate using Bluetooth 4.1 controllers with support for Secure Connections. There is no backward compatibilty if used with older hardware. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
66138ce8 |
|
10-Jan-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Add support for handling P-256 derived link keys Before being able to enable Secure Connections support, the core needs to know on how to handle P-256 derived link keys. The difference between authenticated and unauthenticated P-256 derived link keys is the same as its P-192 counter parts. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
11015c79 |
|
10-Jan-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Add definitions for new link key types With the introduction of Secure Connections, the list of link key types got extended by P-256 versions of authenticated and unauthenticated link keys. To avoid any confusion the previous authenticated and unauthenticated link key types got ammended with a P912 postfix. And the two new keys have a P256 postfix now. Existing code using the previous definitions has been adjusted. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
4e70c7e7 |
|
19-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Expose debugfs settings for LE connection interval For testing purposes expose the default LE connection interval values via debugfs. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
79830f66 |
|
18-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Select the own address type during initial setup phase The own address type is based on the fact if the controller has a public address or not. This means that this detail can be just configured once during setup phase. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
a74a84f6 |
|
16-Oct-2013 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Convert idle timer to use delayed work There is no need to use a timer since the entire Bluetooth subsystem runs using workqueues these days. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
7bc18d9d |
|
16-Oct-2013 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Convert auto accept timer to use delayed work Since the entire Bluetooth subsystem runs in workqueues these days there is no need to use a timer for deferring work. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
662e8820 |
|
13-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Store source address of HCI connections The source addressed was based on the public address of the HCI device, but with LE connections this not always the case. For example single mode LE-only controllers would use a static random address. And this address is configured by userspace. To not complicate the lookup of what kind of address is in use, store the correct source address for each HCI connection. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
e7c4096e |
|
13-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Store the source address type of LE connections When establishing LE connections, it is possible to use a public address (if available) or a random address. The type of address is only known when creating connections, so make sure it is stored in hci_conn structure. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
79d95a19 |
|
13-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Remove pointless bdaddr_to_le() helper function The bdaddr_to_le() function tries to convert the internal address type to one that matches the HCI address type for LE. It does not handle any address types not used by LE and in the end just make the code a lot harder to read. So instead of just hiding behind a magic function, just convert the internal address type where it needs to be converted. And it turns out that these are only two cases anyway. One when creating new LE connections and the other when loading the long term keys. In both cases this makes it more clear on what it going on. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
bef64738 |
|
11-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Make LE scan interval and window a controller option The scan interval and window for LE passive scanning and connection establishment should be configurable on a per controller basis. So introduce a setting that later on will allow modifying it. This setting does not affect LE active scanning during device discovery phase. As long as that phase uses interleaved discovery, it will continuously scan. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
ac4b7236 |
|
10-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Move smp.h header file into net/bluetooth/ The smp.h header file is only used internally by the bluetooth.ko module and is not a public API. So make it local to the core Bluetooth module. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
7024728e |
|
10-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Move a2mp.h header file into net/bluetooth/ The a2mp.h header file is only used internally by the bluetooth.ko module and is not a public API. So make it local to the core Bluetooth module. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
620ad521 |
|
08-Oct-2013 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Refactor hci_connect_le This patch does some code refactoring in hci_connect_le() by moving the exception code into if statements and letting the main flow in first level of function scope. It also adds extra comments to improve the code readability. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
1d399ae5 |
|
08-Oct-2013 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Use HCI request for LE connection This patch introduces a new helper, which uses the HCI request framework, for creating LE connectons. All the handling is now done by this function so we can remove the hci_cs_le_create_conn() event handler. This patch also removes the old hci_le_create_connection() since it is not used anymore. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
c25dfc61 |
|
06-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Use random address if public address is not available For single mode LE-only controllers, it is possible that they come without a public address. If a public address is not available, then use the random address for connection establishment and scanning. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
f3d3444a |
|
04-Oct-2013 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Rename HCI_LE_PERIPHERAL to HCI_ADVERTISING This flag is used to indicate whether we want to have advertising enabled or not, so give it a more suitable name. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
46a190cb |
|
03-Oct-2013 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Initialize hci_conn fields in hci_connect_le This patch moves some hci_conn fields initialization from hci_le_ create_connection() to hci_connect_le(). It makes more sense to initialize these fields within the function that creates the hci_ conn object. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
f1e5d547 |
|
03-Oct-2013 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Rename hci_conn variable in hci_connect_le() This patch simply rename the hci_conn variable "le" to "conn" since it is a better name. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
56f87901 |
|
02-Oct-2013 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Introduce a new HCI_BREDR_ENABLED flag To allow treating dual-mode (BR/EDR/LE) controllers as single-mode ones (LE-only) we want to introduce a new HCI_BREDR_ENABLED flag to track whether BR/EDR is enabled or not (previously we simply looked at the feature bit with lmp_bredr_enabled). This patch add the new flag and updates the relevant places to test against it instead of using lmp_bredr_enabled. The flag is by default enabled when registering an adapter and only cleared if necessary once the local features have been read during the HCI init procedure. We cannot completely block BR/EDR usage in case user space uses raw HCI sockets but the patch tries to block this in places where possible, such as the various BR/EDR specific ioctls. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
af750e94 |
|
03-Sep-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Disable upper layer connections when user channel is active When the device has the user channel flag set, it means it is driven by an user application. In that case do not allow any connections from L2CAP or SCO sockets. This is the same situation as when the device has the raw flag set and it will then return EHOSTUNREACH. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Acked-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
2dea632f |
|
19-Aug-2013 |
Frédéric Dalleau <frederic.dalleau@linux.intel.com> |
Bluetooth: Add SCO connection fallback When initiating a transparent eSCO connection, make use of T2 settings at first try. T2 is the recommended settings from HFP 1.6 WideBand Speech. Upon connection failure, try T1 settings. When CVSD is requested and eSCO is supported, try to establish eSCO connection using S3 settings. If it fails, fallback in sequence to S2, S1, D1, D0 settings. To know which setting should be used, conn->attempt is used. It indicates the currently ongoing SCO connection attempt and can be used as the index for the fallback settings table. These setting and the fallback order are described in Bluetooth HFP 1.6 specification p. 101. Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
10c62ddc |
|
19-Aug-2013 |
Frédéric Dalleau <frederic.dalleau@linux.intel.com> |
Bluetooth: Parameters for outgoing SCO connections In order to establish a transparent SCO connection, the correct settings must be specified in the Setup Synchronous Connection request. For that, a setting field is added to ACL connection data to set up the desired parameters. The patch also removes usage of hdev->voice_setting in CVSD connection and makes use of T2 parameters for transparent data. Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
e660ed6c |
|
19-Aug-2013 |
Frédéric Dalleau <frederic.dalleau@linux.intel.com> |
Bluetooth: Use hci_connect_sco directly hci_connect is a super function for connecting hci protocols. But the voice_setting parameter (introduced in subsequent patches) is only needed by SCO and security requirements are not needed for SCO channels. Thus, it makes sense to have a separate function for SCO. Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
8d12356f |
|
06-Apr-2013 |
David Herrmann <dh.herrmann@gmail.com> |
Bluetooth: introduce hci_conn ref-counting We currently do not allow using hci_conn from outside of HCI-core. However, several other users could make great use of it. This includes HIDP, rfcomm and all other sub-protocols that rely on an active connection. Hence, we now introduce hci_conn ref-counting. We currently never call get_device(). put_device() is exclusively used in hci_conn_del_sysfs(). Hence, we currently never have a greater device-refcnt than 1. Therefore, it is safe to move the put_device() call from hci_conn_del_sysfs() to hci_conn_del() (it's the only caller). In fact, this even fixes a "use-after-free" bug as we access hci_conn after calling hci_conn_del_sysfs() in hci_conn_del(). From now on we can add references to hci_conn objects in other layers (like l2cap_sock, HIDP, rfcomm, ...) and grab a reference via hci_conn_get(). This does _not_ guarantee, that the connection is still alive. But, this isn't what we want. We can simply lock the hci_conn device and use "device_is_registered(hci_conn->dev)" to test that. However, this is hardly necessary as outside users should never rely on the HCI connection to be alive, anyway. Instead, they should solely rely on the device-object to be available. But if sub-devices want the hci_conn object as sysfs parent, they need to be notified when the connection drops. This will be introduced in later patches with l2cap_users. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
fc225c3f |
|
06-Apr-2013 |
David Herrmann <dh.herrmann@gmail.com> |
Bluetooth: remove unneeded hci_conn_hold/put_device() hci_conn_hold/put_device() is used to control when hci_conn->dev is no longer needed and can be deleted from the system. Lets first look how they are currently used throughout the code (excluding HIDP!). All code that uses hci_conn_hold_device() looks like this: ... hci_conn_hold_device(); hci_conn_add_sysfs(); ... On the other side, hci_conn_put_device() is exclusively used in hci_conn_del(). So, considering that hci_conn_del() must not be called twice (which would fail horribly), we know that hci_conn_put_device() is only called _once_ (which is in hci_conn_del()). On the other hand, hci_conn_add_sysfs() must not be called twice, either (it would call device_add twice, which breaks the device, see drivers/base/core.c). So we know that hci_conn_hold_device() is also called only once (it's only called directly before hci_conn_add_sysfs()). So hold and put are known to be called only once. That means we can safely remove them and directly call hci_conn_del_sysfs() in hci_conn_del(). But there is one issue left: HIDP also uses hci_conn_hold/put_device(). However, this case can be ignored and simply removed as it is totally broken. The issue is, the only thing HIDP delays with hci_conn_hold_device() is the removal of the hci_conn->dev from sysfs. But, the hci_conn device has no mechanism to get notified when its own parent (hci_dev) gets removed from sysfs. hci_dev_hold/put() does _not_ control when it is removed but only when the device object is created and destroyed. And hci_dev calls hci_conn_flush_*() when it removes itself from sysfs, which itself causes hci_conn_del() to be called, but it does _not_ cause hci_conn_del_sysfs() to be called, which is wrong. Hence, we fix it to call hci_conn_del_sysfs() in hci_conn_del(). This guarantees that a hci_conn object is removed from sysfs _before_ its parent hci_dev is removed. The changes to HIDP look scary, wrong and broken. However, if you look at the HIDP session management, you will notice they're already broken in the exact _same_ way (ever tried "unplugging" HIDP devices? Breaks _all_ the time). So this patch only makes HIDP look _scary_ and _obviously broken_. It does not break HIDP itself, it already is! See later patches in this series which fix HIDP to use proper session-management. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
93796fa6 |
|
11-Apr-2013 |
Claudio Takahasi <claudio.takahasi@openbossa.org> |
Bluetooth: Reject SCO when hci connection timeouts This patch sends Reject Synchronous Connection Request Command when hci_conn_timeout is triggered, and the SCO connection is in BT_CONNECT2 state. It prevents inconsistency if the remote host doesn't implement properly the timeout for the connection request, and it removes the connection reference left when the socket is closed for incoming SCO connections. [ 2650.129080] sco_sock_release: sock ffff8801ca417400, sk ffff88020c408800 [ 2650.129092] sco_sock_clear_timer: sock ffff88020c408800 state 6 [ 2650.129101] __sco_sock_close: sk ffff88020c408800 state 6 socket ffff8801ca417400 [ 2650.129108] sco_chan_del: sk ffff88020c408800, conn ffff8801c650ea20, err 104 [ 2650.129114] hci_conn_put: hcon ffff88020c40a800 orig refcnt 1 [ 2650.129128] sco_sock_kill: sk ffff88020c408800 state 9 [ 2650.129135] sco_sock_destruct: sk ffff88020c408800 [ 2650.138468] hci_conn_timeout: hcon ffff88020c40a800 state BT_CONNECT2 Signed-off-by: Claudio Takahasi <claudio.takahasi@openbossa.org> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
76a68ba0 |
|
06-Apr-2013 |
David Herrmann <dh.herrmann@gmail.com> |
Bluetooth: rename hci_conn_put to hci_conn_drop We use _get() and _put() for device ref-counting in the kernel. However, hci_conn_put() is _not_ used for ref-counting, hence, rename it to hci_conn_drop() so we can later fix ref-counting and introduce hci_conn_put(). hci_conn_hold() and hci_conn_put() are currently used to manage how long a connection should be held alive. When the last user drops the connection, we spawn a delayed work that performs the disconnect. Obviously, this has nothing to do with ref-counting for the _object_ but rather for the keep-alive of the connection. But we really _need_ proper ref-counting for the _object_ to allow connection-users like rfcomm-tty, HIDP or others. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
bed71748 |
|
30-Jan-2013 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Rename hci_acl_disconn As hci_acl_disconn function basically sends the HCI Disconnect Command and it is used to disconnect ACL, SCO and LE links, renaming it to hci_disconnect is more suitable. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
4c02e2d4 |
|
30-Jan-2013 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Fix hci_conn timeout routine If occurs a LE or SCO hci_conn timeout and the connection is already established (BT_CONNECTED state), the connection is not terminated as expected. This bug can be reproduced using l2test or scotest tool. Once the connection is established, kill l2test/scotest and the connection won't be terminated. This patch fixes hci_conn_disconnect helper so it is able to terminate LE and SCO connections, as well as ACL. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
e9b02748 |
|
25-Oct-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Add put(hcon) when deleting hchan When refcnt reaches zero disconnect timeout will run and hci_conn will be disconnected. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
f1550478 |
|
24-Oct-2012 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Disallow LE scanning and connecting in peripheral role When an adapter is in the LE peripheral role scanning for other devices or initiating connections to them is not allowed. This patch makes sure that such attempts will result in appropriate error returns. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
168df8e5 |
|
23-Oct-2012 |
Mat Martineau <mathewm@codeaurora.org> |
Bluetooth: Add state to hci_chan On an AMP controller, hci_chan maps to a logical link. When a channel is being moved, the logical link may or may not be connected already. The hci_chan->state is used to determine the existance of a useable logical link so the link can be either used or requested. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Acked-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
42c4e53e |
|
10-Oct-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: AMP: Add handle to hci_chan structure hci_chan will be identified by handle used in logical link creation process. This handle is used in AMP ACL-U packet handle field. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
53502d69 |
|
10-Oct-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: AMP: Handle AMP_LINK timeout When AMP_LINK timeouts execute HCI_OP_DISCONN_PHY_LINK as analog to HCI_OP_DISCONNECT for ACL_LINK. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
6ed93dc6 |
|
24-Sep-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Use %pMR in debug instead of batostr Instead of old unsafe batostr function use %pMR print specifier for printing Bluetooth addresses in debug and error statements. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
9472007c |
|
06-Sep-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: trivial: Make hci_chan_del return void Return code is not needed in hci_chan_del Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
d8343f12 |
|
23-Aug-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Fix sending a HCI Authorization Request over LE links In the case that the link is already in the connected state and a Pairing request arrives from the mgmt interface, hci_conn_security() would be called but it was not considering LE links. Reported-by: João Paulo Rechi Vita <jprvita@openbossa.org> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
f91c8468 |
|
17-Aug-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Fix establishing ESCO links Commit 4cd2d98340b4f03d5532c30fdaeb451b035429cb "Bluetooth: Simplify the connection type handling" broke the creation of ESCO links. This patch adds a type parameter to hci_connect_sco() so it creates the connection of the right kind. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
e6dd548b |
|
27-Jul-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Add type information to the hci_connect() debug statement Now that we have a "connect" function for each link type, we should be able to indentify which function is going to be called. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
4cd2d983 |
|
27-Jul-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Simplify a the connection type handling Now that we have separate ways of doing connections for each link type, we can do better than an "if" statement to handle each link type. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
b7d839bf |
|
27-Jul-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Refactor SCO connection into its own function We can do the same that we did for the other link types, for SCO connections. The only thing that's worth noting is that as SCO links need an ACL link, this functions uses the function that adds an ACL link. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
db474275 |
|
28-Jul-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Refactor ACL connection into its own function The hci_connect() function was starting to get too complicated to be quickly understood. We can separate the creation of a new ACL connection into its own function. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
d04aef4c |
|
27-Jul-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Refactor LE connection into its own function The code that handles LE connection is already quite separated from the rest of the connection procedure, so we can easily put it into its own. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
1aef8669 |
|
27-Jul-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Rename LE and ACL connection functions These names were causing much confusion, so we rename these functions that send HCI commands to be more similar in naming to the actual HCI commands that will be sent. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
57f5d0d1 |
|
27-Jul-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Remove some functions from being exported Some connection related functions are only used inside hci_conn.c so no need to have them exported. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
d300fa9b |
|
19-Jun-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Route traffic only through BR/EDR controller If AMP controller is first in the list then Bluetooth traffic might be routed through it (if source is not specified). The patch prevents this case and also checks that source is BR/EDR. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
38b3fef1 |
|
15-Jun-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Improve debugging messages for hci_conn Improve debugging of hci_conn objects by: adding print to hci_conn refcounting, adding object spcifier when missing, change conn to hcon since conn is heavily used for l2cap_conn objects and this is misleading. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
dfc94dbd |
|
30-May-2012 |
Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> |
Bluetooth: Allow only one LE connection attempt Only one outgoing LE connection attempt should be possible. hci_connect() will now return -EBUSY in case there's another pending outgoing connection. Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
9740e49d |
|
29-May-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: A2MP: AMP Manager basic functions Define AMP Manager and some basic functions. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
#
82781e63 |
|
25-May-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Use __constant modifier in HCI code Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
8449e381 |
|
23-May-2012 |
Gustavo Padovan <gustavo.padovan@collabora.co.uk> |
Bluetooth: Remove unneeded EXPORT_SYMBOL After l2cap, sco and bluetooth modules merge some symbols doesn't need to be exported anymore. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
8c520a59 |
|
23-May-2012 |
Gustavo Padovan <gustavo.padovan@collabora.co.uk> |
Bluetooth: Remove unnecessary headers include Most of the include were unnecessary or already included by some other header. Replace module.h by export.h where possible. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
8fc9ced3 |
|
23-May-2012 |
Gustavo Padovan <gustavo.padovan@collabora.co.uk> |
Bluetooth: Fix coding style in the subsystem This is some leftover from the last patches that fixed style. It is mostly line over 80 characters fixes reported by checkpatch.pl. checkpatch.pl is clean for these files now. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
fc5fef61 |
|
23-May-2012 |
Gustavo Padovan <gustavo.padovan@collabora.co.uk> |
Bluetooth: Remove 'register' usage from the subsystem Let the compiler chooses what is best. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
4f42a8cd |
|
23-May-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: trivial: Remove empty line Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
5974e4c4 |
|
16-May-2012 |
Gustavo Padovan <gustavo.padovan@collabora.co.uk> |
Bluetooth: Fix coding style in hci_conn.c Follow net subsystem rules. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
2ee8ce35 |
|
20-Apr-2012 |
Syam Sidhardhan <s.syam@samsung.com> |
Bluetooth: Remove unused hci_le_ltk_neg_reply() No one is using hci_le_ltk_neg_reply() in bluetooth subsystem. Signed-off-by: Syam Sidhardhan <s.syam@samsung.com> Signed-off-by: Gustavo Padovan <gustavo@padovan.org>
|
#
e10b9969 |
|
12-Apr-2012 |
Syam Sidhardhan <s.syam@samsung.com> |
Bluetooth: Remove unused hci_le_ltk_reply() In this API, we were using sizeof operator for an array given as function argument, which is invalid. However this API is not used anywhere. Signed-off-by: Syam Sidhardhan <s.syam@samsung.com> Signed-off-by: Gustavo Padovan <gustavo@padovan.org>
|
#
b12f62cf |
|
24-Apr-2012 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Add dst_type parameter to hci_connect This patch adds the dst_type parameter to hci_connect function. Instead of searching the address type in advertising cache, we use the dst_type parameter to establish LE connections. The dst_type is ignored for BR/EDR connection establishment. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Acked-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
b2905044 |
|
24-Apr-2012 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Remove useless code in hci_connect This patch removes unneeded variable assignments in hci_connect. 'sec_level' is already assigned to BT_SECURITY_LOW in hci_le_connect and 'pending_sec_level' and 'auth_type' are assigned right after if statement. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
9f0caeb1 |
|
20-Apr-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Add support for reusing the same hci_conn for LE links As most LE devices leave advertising mode when they enter the connected state, we may want to "pass" that connection to other users. The first user will be the pairing procedure, the connection is established without an associated socket, after the pairing is complete, userspace may want to discover via GATT what services the newly bonded device has. If userspace establishes the connection while the timeout still hasn't expired, the connection will be re-used. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Tested-by: João Paulo Rechi Vita <jprvita@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo@padovan.org>
|
#
9ffc93f2 |
|
28-Mar-2012 |
David Howells <dhowells@redhat.com> |
Remove all #inclusions of asm/system.h Remove all #inclusions of asm/system.h preparatory to splitting and killing it. Performed with the following command: perl -p -i -e 's!^#\s*include\s*<asm/system[.]h>.*\n!!' `grep -Irl '^#\s*include\s*<asm/system[.]h>' *` Signed-off-by: David Howells <dhowells@redhat.com>
|
#
70c1f20b |
|
21-Feb-2012 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Fix two minor style issues in HCI code WARNING: min() should probably be min_t(__u16, scb->expect, count) + len = min(scb->expect, (__u16)count); WARNING: Statements terminations use 1 semicolon + INIT_LIST_HEAD(&conn->chan_list);; Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
040030ef |
|
20-Feb-2012 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Remove HCI notifier handling The HCI notifier handling was never used outside of Bluetooth core layer and thus remove it and replace it with direct function calls. Also move the stack internal event generation into the HCI socket layer. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
48c7aba9 |
|
19-Feb-2012 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix hci_connect error return values The hci_connect function should either return a valid hci_conn pointer or a ERR_PTR() but never NULL. This patch fixes the two places where hci_conn_add failures would have caused a NULL return. The only reason for failure with hci_conn_add is memory allocation so ENOMEM seems to be a good choice here. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
|
#
42d2d87c |
|
17-Feb-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Prefix hex numbers with object name Several hex numbers were printed without object name which complicates debugging. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
e05dcc32 |
|
17-Feb-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Use symbolic names for state in debug Use state_to_string function in debug statements. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
18daf164 |
|
13-Jan-2012 |
Peter Hurley <peter@hurleysoftware.com> |
Bluetooth: Fix l2cap conn failures for ssp devices Commit 330605423c fixed l2cap conn establishment for non-ssp remote devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security is tested (which was always returning failure on any subsequent security checks). However, this broke l2cap conn establishment for ssp remote devices when an ACL link was already established at SDP-level security. This fix ensures that encryption must be pending whenever authentication is also pending. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
2a5a5ec6 |
|
02-Feb-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Use list _safe deleting from conn chan_list Fixes possible bug when deleting element from the list in function hci_chan_list_flush. list_for_each_entry_rcu is used and after deleting element from the list we also free pointer and then list_entry_rcu is taken from freed pointer. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
3c4e0df0 |
|
02-Feb-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Use list _safe deleting from conn_hash_list Use list_for_each_entry_safe which is safe version against removal of list entry. Otherwise we remove hci_conn element and reference next element which result in accessing LIST_POISON. [ 95.571834] Bluetooth: unknown link type 127 [ 95.578349] BUG: unable to handle kernel paging request at 20002000 [ 95.580236] IP: [<20002000>] 0x20001fff [ 95.580763] *pde = 00000000 [ 95.581196] Oops: 0000 [#1] SMP ... [ 95.582298] Pid: 3355, comm: hciconfig Tainted: G O 3.2.0-VirttualBox [ 95.582298] EIP: 0060:[<20002000>] EFLAGS: 00210206 CPU: 0 [ 95.582298] EIP is at 0x20002000 ... [ 95.582298] Call Trace: [ 95.582298] [<f8231ab6>] ? hci_conn_hash_flush+0x76/0xf0 [bluetooth] [ 95.582298] [<f822bcb1>] hci_dev_do_close+0xc1/0x2e0 [bluetooth] [ 95.582298] [<f822d679>] ? hci_dev_get+0x69/0xb0 [bluetooth] [ 95.582298] [<f822e1da>] hci_dev_close+0x2a/0x50 [bluetooth] [ 95.582298] [<f824102f>] hci_sock_ioctl+0x1af/0x3f0 [bluetooth] [ 95.582298] [<c11153ea>] ? handle_pte_fault+0x8a/0x8f0 [ 95.582298] [<c146becf>] sock_ioctl+0x5f/0x260 [ 95.582298] [<c146be70>] ? sock_fasync+0x90/0x90 [ 95.582298] [<c1152b33>] do_vfs_ioctl+0x83/0x5b0 [ 95.582298] [<c1563f87>] ? do_page_fault+0x297/0x500 [ 95.582298] [<c1563cf0>] ? spurious_fault+0xd0/0xd0 [ 95.582298] [<c107165b>] ? up_read+0x1b/0x30 [ 95.582298] [<c1563f87>] ? do_page_fault+0x297/0x500 [ 95.582298] [<c100aa9f>] ? init_fpu+0xef/0x160 [ 95.582298] [<c15617c0>] ? do_debug+0x180/0x180 [ 95.582298] [<c100a958>] ? fpu_finit+0x28/0x80 [ 95.582298] [<c11530e7>] sys_ioctl+0x87/0x90 [ 95.582298] [<c156795f>] sysenter_do_call+0x12/0x38 ... Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
b7d05bad |
|
13-Jan-2012 |
Peter Hurley <peter@hurleysoftware.com> |
Bluetooth: Fix l2cap conn failures for ssp devices Commit 330605423c fixed l2cap conn establishment for non-ssp remote devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security is tested (which was always returning failure on any subsequent security checks). However, this broke l2cap conn establishment for ssp remote devices when an ACL link was already established at SDP-level security. This fix ensures that encryption must be pending whenever authentication is also pending. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
e72acc13 |
|
27-Jan-2012 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Remove unneeded locking We don't need locking hdev in hci_conn_timeout() since it doesn't access any hdev's shared resources, it basically queues HCI commands. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Reviewed-by: Ulisses Furquim <ulisses@profusion.mobi> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
75d7735c |
|
30-Jan-2012 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Use GFP_KERNEL in hci_chan_create() This function is called in process context only, so it should use GFP_KERNEL to allocate memory. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
cb601d7e |
|
30-Jan-2012 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Use GFP_KERNEL in hci_conn_add() This function is called in process context only, so it should use GFP_KERNEL to allocate memory. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
#
aa64a8b5 |
|
18-Jan-2012 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Add a convenience function to check for SSP enabled It's a very common test to see if both the local and the remote device have SSP enabled. By creating a simple function to test this we can shorten many if-statements in the code. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
|
#
84bde9d6 |
|
25-Jan-2012 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Convert hdev->ssp_mode to a flag The ssp_mode is essentially just a boolean so it's more appropriate to have it simply as a flag in hdev->dev_flags. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
|
#
58a681ef |
|
15-Jan-2012 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Merge boolean members of struct hci_conn into flags Now that the flags member of struct hci_conn is supposed to accommodate any boolean type values we can easily merge all boolean members into it. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
|
#
a0c808b3 |
|
16-Jan-2012 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Convert hdev->out to a bool type The hdev->out variable is essentially a boolean so the type 'bool' makes more sense than u8. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
|
#
51a8efd7 |
|
15-Jan-2012 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Rename conn->pend to conn->flags These flags can and will be used for more general purpose values than just pending state transitions so the more common name "flags" makes more sense than "pend". Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
|
#
f20d09d5 |
|
22-Dec-2011 |
Gustavo Padovan <padovan@profusion.mobi> |
Bluetooth: remove *_bh usage from hci_dev_list and hci_cb_list They don't need to disable interrupts anymore, we only run in process context now. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
d7660918 |
|
18-Dec-2011 |
Gustavo Padovan <padovan@profusion.mobi> |
Revert "Bluetooth: Revert: Fix L2CAP connection establishment" This reverts commit 4dff523a913197e3314c7b0d08734ab037709093. It was reported that this patch cause issues when trying to connect to legacy devices so reverting it. Reported-by: David Fries <david@fries.net> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
3c54711c |
|
14-Dec-2011 |
Gustavo Padovan <padovan@profusion.mobi> |
Bluetooth: Don't disable tasklets to call hdev->notify() It's pointless, we aren't protecting anything since btusb_notify() schedules a work to run, then all it operation happens without protection. If protection is really needed here, we will fix it further. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
bf4c6325 |
|
14-Dec-2011 |
Gustavo Padovan <padovan@profusion.mobi> |
Bluetooth: convert conn hash to RCU Handling hci_conn_hash with RCU make us avoid some locking and disable tasklets. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
8192edef |
|
14-Dec-2011 |
Gustavo Padovan <padovan@profusion.mobi> |
Bluetooth: Use RCU to manipulate chan_list Instead of using tasklet_disable() to prevent acess to the channel use, we can use RCU and improve the performance of our code. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
b9cc553f |
|
16-Jun-2011 |
Gustavo Padovan <padovan@profusion.mobi> |
Bluetooth: hci_conn_auto_accept() doesn't need locking It doesn't really touch any sensitive information about hdev. So no need to lock here. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
19c40e3b |
|
17-Jun-2011 |
Gustavo Padovan <padovan@profusion.mobi> |
Bluetooth: Use delayed_work for connection timeout Bluetooth rx task runs now in a workqueue, so it a good approach run any timer that share locking with process context code also in a workqueue. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
09fd0de5 |
|
17-Jun-2011 |
Gustavo Padovan <padovan@profusion.mobi> |
Bluetooth: Replace spin_lock by mutex in hci_dev Now we run everything in HCI in process context, so it's a better idea use mutex instead spin_lock. The macro remains hci_dev_lock() (and I got rid of hci_dev_lock_bh()), of course. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
416dc94b |
|
07-Dec-2011 |
Gustavo Padovan <padovan@profusion.mobi> |
Bluetooth: make hci_conn_enter_sniff_mode static It isn't used outside hci_conn.c Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
3e9c40a6 |
|
14-Dec-2011 |
Gustavo Padovan <padovan@profusion.mobi> |
Bluetooth: Use list_for_each_entry in hci_conn_hash_flush() Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
2c33c06a |
|
14-Dec-2011 |
Gustavo Padovan <padovan@profusion.mobi> |
Bluetooth: remove struct hci_chan_hash Only the list member of the struct was used, so we now fold it into hci_conn. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
d095c1eb |
|
01-Dec-2011 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Remove magic bluetooth version numbers Use bluetooth names instead of BT SIG assigned numbers Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
9f5a0d7b |
|
07-Nov-2011 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Define HCI reasons instead of magic number Use HCI error reasons instead of magic numbers. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
73d80deb |
|
02-Nov-2011 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: prioritizing data over HCI This implement priority based scheduler using skbuffer priority set via SO_PRIORITY socket option. It introduces hci_chan_hash (list of HCI Channel/hci_chan) per connection, each item in this list refer to a L2CAP connection and it is used to queue the data for transmission. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
8035ded4 |
|
01-Nov-2011 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: replace list_for_each with list_for_each_entry whenever possible When all items in the list have the same type there is no much of a point to use list_for_each except if you want to use the list pointer itself. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
4dff523a |
|
26-Oct-2011 |
Arek Lichwa <arkadiusz.lichwa@tieto.com> |
Bluetooth: Revert: Fix L2CAP connection establishment This reverts commit 330605423ca6eafafb8dcc27502bce1c585d1b06. The commit introduces regression when two 2.1 devices attempt establish rfcomm channel. Such connection is refused since there's a security block issue on l2cap. It means the link is unencrypted. 2011-09-16 18:08:46.567616 < ACL data: handle 1 flags 0x00 dlen 24 0000: 14 00 40 00 06 00 02 00 0f 35 03 19 12 00 ff ff ..@......5....˙˙ 0010: 35 05 0a 00 00 ff ff 00 5....˙˙. 2011-09-16 18:08:46.572377 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1 2011-09-16 18:08:46.577931 > ACL data: handle 1 flags 0x02 dlen 88 L2CAP(d): cid 0x0040 len 84 [psm 0] 0000: 07 00 02 00 4f 00 4c 35 4a 35 48 09 00 00 0a 00 ....O.L5J5H..... 0010: 01 00 00 09 00 01 35 03 19 12 00 09 00 05 35 03 ......5.......5. 0020: 19 10 02 09 00 09 35 08 35 06 19 12 00 09 01 02 ......5.5....... 0030: 09 02 00 09 01 02 09 02 01 09 00 0a 09 02 02 09 ................ 0040: 00 00 09 02 03 09 00 00 09 02 04 28 01 09 02 05 ...........(.... 0050: 09 00 02 00 .... 2011-09-16 18:08:46.626057 < HCI Command: Authentication Requested (0x01|0x0011) plen 2 handle 1 2011-09-16 18:08:46.627614 > HCI Event: Command Status (0x0f) plen 4 Authentication Requested (0x01|0x0011) status 0x00 ncmd 1 2011-09-16 18:08:46.627675 > HCI Event: Link Key Request (0x17) plen 6 bdaddr 00:00:F2:6A:29:69 2011-09-16 18:08:46.634999 < HCI Command: Link Key Request Reply (0x01|0x000b) plen 22 bdaddr 00:00:F2:6A:29:69 key 58CD393179FC902E5E8F512A855EE532 2011-09-16 18:08:46.683278 > HCI Event: Command Complete (0x0e) plen 10 Link Key Request Reply (0x01|0x000b) ncmd 1 status 0x00 bdaddr 00:00:F2:6A:29:69 2011-09-16 18:08:46.764729 > HCI Event: Auth Complete (0x06) plen 3 status 0x00 handle 1 2011-09-16 18:08:46.764821 < ACL data: handle 1 flags 0x00 dlen 12 0000: 08 00 01 00 02 05 04 00 03 00 41 00 ..........A. 2011-09-16 18:08:46.764851 > HCI Event: Command Status (0x0f) plen 4 Unknown (0x00|0x0000) status 0x00 ncmd 2 2011-09-16 18:08:46.768117 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1 2011-09-16 18:08:46.770894 > ACL data: handle 1 flags 0x02 dlen 16 L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0041 result 3 status 0 Connection refused - security block 2011-09-16 18:08:49.000691 < ACL data: handle 1 flags 0x00 dlen 12 0000: 08 00 01 00 06 06 04 00 40 00 40 00 ........@.@. 2011-09-16 18:08:49.015675 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 1 packets 1 2011-09-16 18:08:49.016927 > ACL data: handle 1 flags 0x02 dlen 12 L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040 2011-09-16 18:08:51.009480 < HCI Command: Disconnect (0x01|0x0006) plen 3 handle 1 reason 0x13 Reason: Remote User Terminated Connection 2011-09-16 18:08:51.011525 > HCI Event: Command Status (0x0f) plen 4 Disconnect (0x01|0x0006) status 0x00 ncmd 1 2011-09-16 18:08:51.123494 > HCI Event: Disconn Complete (0x05) plen 4 status 0x00 handle 1 reason 0x16 Reason: Connection Terminated by Local Host Signed-off-by: Arek Lichwa <arkadiusz.lichwa@tieto.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
0e833915 |
|
27-Jul-2011 |
Anderson Lizardo <anderson.lizardo@openbossa.org> |
Bluetooth: use recommended LE connection parameters The new connection parameters now match the recommended values for Proximity and Health Thermometer profiles. The previous values were ramdomly chosen, and are either too low or too high for most cases. New values: Scan Interval: 60 ms Scan Window: 30 ms Minimum Connection Interval: 50 ms Maximum Connection Interval: 70 ms Supervision Timeout: 420 ms See "Table 5.2: Recommended Scan Interval and Scan Window Values" and "Table 5.3: Recommended Connection Interval Values" for both profiles for details. Note that the "fast connection" parameters were chosen, because we do not support yet dynamically changing these parameters from initiator side. Additionally, the Proximity profile recommends (section "4.4 Alert on Link Loss"): "It is recommended that the Link Supervision Timeout (LSTO) is set to 6x the connection interval." Minimum_CE_Length and Maximum_CE_Length were also changed from 0x0001 to 0x0000 because they are informational and optional, and old value was not reflecting reality. Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
51beabdf |
|
19-Sep-2011 |
Anderson Briglia <anderson.briglia@openbossa.org> |
Bluetooth: Fix wrong memcpy size on LE start encryption This patch fixes wrong memcpy size when copying rand value to HCI_OP_LE_START_ENC command. The compiler pretends that the array parameter was declared as a pointer and sizeof reports the size of the pointer. [1] [1] http://www.c-faq.com/aryptr/aryparmsize.html Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org> Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
163f4dab |
|
30-Jun-2011 |
Tomas Targownik <ttargownik@geicp.com> |
Bluetooth: Fix memory leak under page timeouts If the remote device is not present, the connections attemp fails and the struct hci_conn was not freed Signed-off-by: Tomas Targownik <ttargownik@geicp.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
33060542 |
|
14-Jun-2011 |
Ilia Kolomisnky <ilia.kolominsky@gmail.com> |
Bluetooth: Fix L2CAP connection establishment In hci_conn_security ( which is used during L2CAP connection establishment ) test for HCI_CONN_ENCRYPT_PEND state also sets this state, which is bogus and leads to connection time-out on L2CAP sockets in certain situations (especially when using non-ssp devices ) Signed-off-by: Ilia Kolomisnky <iliak@ti.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
7b5c0d52 |
|
09-Jun-2011 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Fix initial security level of LE links As the default security level (BT_SECURITY_SDP) doesn't make sense for LE links, initialize LE links with something that makes sense. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
a7a595f6 |
|
09-Jun-2011 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Add support for LE Start Encryption This adds support for starting SMP Phase 2 Encryption, when the initial SMP negotiation is successful. This adds the LE Start Encryption and LE Long Term Key Request commands and related events. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
6fdf658c |
|
13-Jun-2011 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: Fix L2CAP security check With older userspace versions (using hciops) it might not have the key type to check if the key has sufficient security for any security level so it is necessary to check the return of hci_conn_auth to make sure the connection is authenticated Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Acked-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
ef4177e2 |
|
02-Jun-2011 |
Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com> |
Bluetooth: Simplify hci_conn_accept_secure check If the link key is secure (authenticated or combination 16 digit) the sec_level will be always BT_SECURITY_HIGH. Therefore, instead of checking the link key type simply check the sec_level on the link. Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
14b12d0b |
|
23-May-2011 |
Jaikumar Ganesh <jaikumar@google.com> |
Bluetooth: Add BT_POWER L2CAP socket option. Add BT_POWER socket option used to control the power characteristics of the underlying ACL link. When the remote end has put the link in sniff mode and the host stack wants to send data we need need to explicitly exit sniff mode to work well with certain devices (For example, A2DP on Plantronics Voyager 855). However, this causes problems with HID devices. Hence, moving into active mode when sending data, irrespective of who set the sniff mode has been made as a socket option. By default, we will move into active mode. HID devices can set the L2CAP socket option to prevent this from happening. Currently, this has been implemented for L2CAP sockets. This has been tested with incoming and outgoing L2CAP sockets for HID and A2DP. Based on discussions on linux-bluetooth and patches submitted by Andrei Emeltchenko. Signed-off-by: Jaikumar Ganesh <jaikumar@google.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
6d3ce0e7 |
|
31-May-2011 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Set 'peer_addr_type' in hci_le_connect() Set the 'peer_addr_type' field of the LE Create Connection command sent in hci_le_connect(). Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Acked-by: Ville Tervo <ville.tervo@nokia.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
eda42b50 |
|
31-May-2011 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Check advertising cache in hci_connect() When connecting to a LE device, we need to check the advertising cache in order to know the address type of that device. If its advertising entry is not found, the connection is not established and hci_connect() returns error. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Acked-by: Ville Tervo <ville.tervo@nokia.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
893d6751 |
|
31-May-2011 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Remove useless check in hci_connect() There is no need to check the connection's state since hci_conn_add() has just created a new connection and its state has been set properly. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Acked-by: Ville Tervo <ville.tervo@nokia.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
19f8def0 |
|
31-May-2011 |
Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com> |
Bluetooth: Fix auth_complete_evt for legacy units Legacy devices don't re-authenticate the link properly if a link key already exists. Thus, don't update sec_level for this case even if hci_auth_complete_evt indicates success. Otherwise the sec_level will not reflect a real security on the link. Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
b3b1b061 |
|
06-May-2011 |
Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com> |
Bluetooth: Double check sec req for pre 2.1 device In case of pre v2.1 devices authentication request will return success immediately if the link key already exists without any authentication process. That means, it's not possible to re-authenticate the link if you already have combination key and for instance want to re-authenticate to get the high security (use 16 digit pin). Therefore, it's necessary to check security requirements on auth complete event to prevent not enough secure connection. Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
9f61656a |
|
28-Apr-2011 |
Johan Hedberg <johan.hedberg@nokia.com> |
Bluetooth: Add variable SSP auto-accept delay support Some test systems require an arbitrary delay to the auto-accept test cases for Secure Simple Pairing in order for the tests to pass. Previously when this was handled in user space it was worked around by code modifications and recompilation, but now that it's on the kernel side it's more convenient if there's a debugfs interface for it. Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
13d39315 |
|
27-Apr-2011 |
Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com> |
Bluetooth: Map sec_level to link key requirements Keep the link key type together with connection and use it to map security level to link key requirements. Authenticate and/or encrypt connection if the link is insufficiently secure. Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
30e76272 |
|
22-Feb-2011 |
Ville Tervo <ville.tervo@nokia.com> |
Bluetooth: Use ERR_PTR as return error from hci_connect Use ERR_PTR mechanism to return error from hci_connect. Signed-off-by: Ville Tervo <ville.tervo@nokia.com> Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
15c4794f |
|
21-Feb-2011 |
Anderson Briglia <anderson.briglia@openbossa.org> |
Bluetooth: Fix LE conn creation This patch prevents a crash when remote host tries to create a LE link which already exists. i.e.: call l2test twice passing the same parameters. Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org> Signed-off-by: Ville Tervo <ville.tervo@nokia.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
a9583556 |
|
18-Feb-2011 |
Johan Hedberg <johan.hedberg@nokia.com> |
Bluetooth: Fix inititial value for remote authentication requirements The remote authentication requirements for conections need to be initialized to 0xff (unknown) since it is possible that we receive a IO Capability Request before we have received information about the remote requirements. Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
2ce603eb |
|
16-Feb-2011 |
Claudio Takahasi <claudio.takahasi@openbossa.org> |
Bluetooth: Send LE Connection Update Command If the new connection update parameter are accepted, the LE master host sends the LE Connection Update Command to its controller informing the new requested parameters. Signed-off-by: Claudio Takahasi <claudio.takahasi@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
b92a6223 |
|
10-Feb-2011 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Fix initiated LE connections Fix LE connections not being marked as master. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
6ed58ec5 |
|
10-Feb-2011 |
Ville Tervo <ville.tervo@nokia.com> |
Bluetooth: Use LE buffers for LE traffic Bluetooth chips may have separate buffers for LE traffic. This patch add support to use LE buffers provided by the chip. Signed-off-by: Ville Tervo <ville.tervo@nokia.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
fcd89c09 |
|
10-Feb-2011 |
Ville Tervo <ville.tervo@nokia.com> |
Bluetooth: Add LE connect support Bluetooth V4.0 adds support for Low Energy (LE) connections. Specification introduces new set of hci commands to control LE connection. This patch adds logic to create, cancel and disconnect LE connections. Signed-off-by: Ville Tervo <ville.tervo@nokia.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
17fa4b9d |
|
25-Jan-2011 |
Johan Hedberg <johan.hedberg@nokia.com> |
Bluetooth: Add set_io_capability management command This patch adds a new set_io_capability management command which is used to set the IO capability for Secure Simple Pairing (SSP) as well as the Security Manager Protocol (SMP). The value is per hci_dev and each hci_conn object inherits it upon creation. Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
765c2a96 |
|
18-Jan-2011 |
Johan Hedberg <johan.hedberg@nokia.com> |
Bluetooth: Fix race condition with conn->sec_level The conn->sec_level value is supposed to represent the current level of security that the connection has. However, by assigning to it before requesting authentication it will have the wrong value during the authentication procedure. To fix this a pending_sec_level variable is added which is used to track the desired security level while making sure that sec_level always represents the current level of security. Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
65cf686e |
|
18-Jan-2011 |
Johan Hedberg <johan.hedberg@nokia.com> |
Bluetooth: Fix MITM protection requirement preservation If an existing connection has a MITM protection requirement (the first bit of the auth_type) then that requirement should not be cleared by new sockets that reuse the ACL but don't have that requirement. Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
88644bb9 |
|
18-Jan-2011 |
Johan Hedberg <johan.hedberg@nokia.com> |
Revert "Bluetooth: Update sec_level/auth_type for already existing connections" This reverts commit 045309820afe047920a50de25634dab46a1e851d. That commit is wrong for two reasons: - The conn->sec_level shouldn't be updated without performing authentication first (as it's supposed to represent the level of security that the existing connection has) - A higher auth_type value doesn't mean "more secure" like the commit seems to assume. E.g. dedicated bonding with MITM protection is 0x03 whereas general bonding without MITM protection is 0x04. hci_conn_auth already takes care of updating conn->auth_type so hci_connect doesn't need to do it. Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
70f23020 |
|
01-Dec-2010 |
Andrei Emeltchenko <andrei.emeltchenko@nokia.com> |
Bluetooth: clean up hci code Do not use assignment in IF condition, remove extra spaces, fixing typos, simplify code. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
#
e73439d8 |
|
26-Jul-2010 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Defer SCO setup if mode change is pending Certain headsets such as the Motorola H350 will reject SCO and eSCO connection requests while the ACL is transitioning from sniff mode to active mode. Add synchronization so that SCO and eSCO connection requests will wait until the ACL has fully transitioned to active mode. < HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2 handle 12 > HCI Event: Command Status (0x0f) plen 4 Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17 handle 12 voice setting 0x0040 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 12 packets 1 > HCI Event: Mode Change (0x14) plen 6 status 0x00 handle 12 mode 0x00 interval 0 Mode: Active > HCI Event: Synchronous Connect Complete (0x2c) plen 17 status 0x10 handle 14 bdaddr 00:1A:0E:50:28:A4 type SCO Error: Connection Accept Timeout Exceeded Signed-off-by: Ron Shaffer <rshaffer@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
2d0a0346 |
|
28-May-2010 |
Ron Shaffer <rshaffer@codeaurora.org> |
Bluetooth: Reassigned copyright to Code Aurora Forum Qualcomm, Inc. has reassigned rights to Code Aurora Forum. Accordingly, as files are modified by Code Aurora Forum members, the copyright statement will be updated. Signed-off-by: Ron Shaffer <rshaffer@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
04530982 |
|
15-Jun-2010 |
Ville Tervo <ville.tervo@nokia.com> |
Bluetooth: Update sec_level/auth_type for already existing connections Update auth level for already existing connections if it is lower than required by new connection. Signed-off-by: Ville Tervo <ville.tervo@nokia.com> Reviewed-by: Emeltchenko Andrei <andrei.emeltchenko@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
c390216b |
|
13-Nov-2009 |
Nick Pelly <npelly@google.com> |
Bluetooth: Enter active mode before establishing a SCO link. When in sniff mode with a long interval time (1.28s) it can take 4+ seconds to establish a SCO link. Fix by requesting active mode before requesting SCO connection. This improves SCO setup time to ~500ms. Bluetooth headsets that use a long interval time, and exhibit the long SCO connection time include Motorola H790, HX1 and H17. They have a CSR 2.1 chipset. Verified this behavior and fix with host Bluetooth chipsets: BCM4329 and TI1271. 2009-10-13 14:17:46.183722 > HCI Event: Mode Change (0x14) plen 6 status 0x00 handle 1 mode 0x02 interval 2048 Mode: Sniff 2009-10-13 14:17:53.436285 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17 handle 1 voice setting 0x0060 2009-10-13 14:17:53.445593 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 2009-10-13 14:17:57.788855 > HCI Event: Synchronous Connect Complete 0x2c) plen 17 status 0x00 handle 257 bdaddr 00:1A:0E:F1:A4:7F type eSCO Air mode: CVSD Signed-off-by: Nick Pelly <npelly@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
93f19c9f |
|
02-Sep-2009 |
Andrei Emeltchenko <andrei.emeltchenko@nokia.com> |
Bluetooth: Set general bonding security for ACL by default This patch fixes double pairing issues with Secure Simple Paring support. It was observed that when pairing with SSP enabled, that the confirmation will be asked twice. http://www.spinics.net/lists/linux-bluetooth/msg02473.html This also causes bug when initiating SSP connection from Windows Vista. The reason is because bluetoothd does not store link keys since HCIGETAUTHINFO returns 0. Setting default to general bonding fixes these issues. Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
9eba32b8 |
|
22-Aug-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Add extra device reference counting for connections The device model itself has no real usable reference counting at the moment and this causes problems if parents are deleted before their children. The device model itself handles the memory details of this correctly, but the uevent order is not consistent. This causes various problems for systems like HAL or even X. So until device_put() does a proper cleanup, the device for Bluetooth connection will be protected with an extra reference counting to ensure the correct order of uevents when connections are terminated. This is not an automatic feature. Higher Bluetooth layers like HIDP or BNEP should grab this new reference to ensure that their uevents are send before the ones from the parent device. Based on a report by Brian Rogers <brian@xyzw.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
1b0336bb |
|
09-May-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Don't use hci_acl_connect_cancel() for incoming connections The connection setup phase takes around 2 seconds or longer and in that time it is possible that the need for an ACL connection is no longer present. If that happens then, the connection attempt will be canceled. This only applies to outgoing connections, but currently it can also be triggered by incoming connection. Don't call hci_acl_connect_cancel() on incoming connection since these have to be either accepted or rejected in this state. Once they are successfully connected they need to be fully disconnected anyway. Also remove the wrong hci_acl_disconn() call for SCO and eSCO links since at this stage they can't be disconnected either, because the connection handle is still unknown. Based on a report by Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Tested-by: Johan Hedberg <johan.hedberg@nokia.com>
|
#
384943ec |
|
08-May-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Fix wrong module refcount when connection setup fails The module refcount is increased by hci_dev_hold() call in hci_conn_add() and decreased by hci_dev_put() call in del_conn(). In case the connection setup fails, hci_dev_put() is never called. Procedure to reproduce the issue: # hciconfig hci0 up # lsmod | grep btusb -> "used by" refcount = 1 # hcitool cc <non-exisiting bdaddr> -> will get timeout # lsmod | grep btusb -> "used by" refcount = 2 # hciconfig hci0 down # lsmod | grep btusb -> "used by" refcount = 1 # rmmod btusb -> ERROR: Module btusb is in use The hci_dev_put() call got moved into del_conn() with the 2.6.25 kernel to fix an issue with hci_dev going away before hci_conn. However that change was wrong and introduced this problem. When calling hci_conn_del() it has to call hci_dev_put() after freeing the connection details. This handling should be fully symmetric. The execution of del_conn() is done in a work queue and needs it own calls to hci_dev_hold() and hci_dev_put() to ensure that the hci_dev stays until the connection cleanup has been finished. Based on a report by Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Tested-by: Bing Zhao <bzhao@marvell.com>
|
#
a67e899c |
|
02-May-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Fix issue with sysfs handling for connections Due to a semantic changes in flush_workqueue() the current approach of synchronizing the sysfs handling for connections doesn't work anymore. The whole approach is actually fully broken and based on assumptions that are no longer valid. With the introduction of Simple Pairing support, the creation of low-level ACL links got changed. This change invalidates the reason why in the past two independent work queues have been used for adding/removing sysfs devices. The adding of the actual sysfs device is now postponed until the host controller successfully assigns an unique handle to that link. So the real synchronization happens inside the controller and not the host. The only left-over problem is that some internals of the sysfs device handling are not initialized ahead of time. This leaves potential access to invalid data and can cause various NULL pointer dereferences. To fix this a new function makes sure that all sysfs details are initialized when an connection attempt is made. The actual sysfs device is only registered when the connection has been successfully established. To avoid a race condition with the registration, the check if a device is registered has been moved into the removal work. As an extra protection two flush_work() calls are left in place to make sure a previous add/del work has been completed first. Based on a report by Marc Pignat <marc.pignat@hevs.ch> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Tested-by: Justin P. Mattock <justinmattock@gmail.com> Tested-by: Roger Quadros <ext-roger.quadros@nokia.com> Tested-by: Marc Pignat <marc.pignat@hevs.ch>
|
#
3fdca1e1 |
|
28-Apr-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Fix connection establishment with low security requirement The Bluetooth 2.1 specification introduced four different security modes that can be mapped using Legacy Pairing and Simple Pairing. With the usage of Simple Pairing it is required that all connections (except the ones for SDP) are encrypted. So even the low security requirement mandates an encrypted connection when using Simple Pairing. When using Legacy Pairing (for Bluetooth 2.0 devices and older) this is not required since it causes interoperability issues. To support this properly the low security requirement translates into different host controller transactions depending if Simple Pairing is supported or not. However in case of Simple Pairing the command to switch on encryption after a successful authentication is not triggered for the low security mode. This patch fixes this and actually makes the logic to differentiate between Simple Pairing and Legacy Pairing a lot simpler. Based on a report by Ville Tervo <ville.tervo@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
052b30b0 |
|
26-Apr-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Add different pairing timeout for Legacy Pairing The Bluetooth stack uses a reference counting for all established ACL links and if no user (L2CAP connection) is present, the link will be terminated to save power. The problem part is the dedicated pairing when using Legacy Pairing (Bluetooth 2.0 and before). At that point no user is present and pairing attempts will be disconnected within 10 seconds or less. In previous kernel version this was not a problem since the disconnect timeout wasn't triggered on incoming connections for the first time. However this caused issues with broken host stacks that kept the connections around after dedicated pairing. When the support for Simple Pairing got added, the link establishment procedure needed to be changed and now causes issues when using Legacy Pairing When using Simple Pairing it is possible to do a proper reference counting of ACL link users. With Legacy Pairing this is not possible since the specification is unclear in some areas and too many broken Bluetooth devices have already been deployed. So instead of trying to deal with all the broken devices, a special pairing timeout will be introduced that increases the timeout to 60 seconds when pairing is triggered. If a broken devices now puts the stack into an unforeseen state, the worst that happens is the disconnect timeout triggers after 120 seconds instead of 4 seconds. This allows successful pairings with legacy and broken devices now. Based on a report by Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
2ae9a6be |
|
21-Feb-2009 |
Dave Young <hidave.darkstar@gmail.com> |
Bluetooth: Move hci_conn_del_sysfs() back to avoid device destruct too early The following commit introduce a regression: commit 7d0db0a373195385a2e0b19d1f5e4b186fdcffac Author: Marcel Holtmann <marcel@holtmann.org> Date: Mon Jul 14 20:13:51 2008 +0200 [Bluetooth] Use a more unique bus name for connections I get panic as following (by netconsole): [ 2709.344034] usb 5-1: new full speed USB device using uhci_hcd and address 4 [ 2709.505776] usb 5-1: configuration #1 chosen from 1 choice [ 2709.569207] Bluetooth: Generic Bluetooth USB driver ver 0.4 [ 2709.570169] usbcore: registered new interface driver btusb [ 2845.742781] BUG: unable to handle kernel paging request at 6b6b6c2f [ 2845.742958] IP: [<c015515c>] __lock_acquire+0x6c/0xa80 [ 2845.743087] *pde = 00000000 [ 2845.743206] Oops: 0002 [#1] SMP [ 2845.743377] last sysfs file: /sys/class/bluetooth/hci0/hci0:6/type [ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev [ 2845.743742] [ 2845.743742] Pid: 0, comm: swapper Not tainted (2.6.29-rc5-smp #54) Dell DM051 [ 2845.743742] EIP: 0060:[<c015515c>] EFLAGS: 00010002 CPU: 0 [ 2845.743742] EIP is at __lock_acquire+0x6c/0xa80 [ 2845.743742] EAX: 00000046 EBX: 00000046 ECX: 6b6b6b6b EDX: 00000002 [ 2845.743742] ESI: 6b6b6b6b EDI: 00000000 EBP: c064fd14 ESP: c064fcc8 [ 2845.743742] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ 2845.743742] Process swapper (pid: 0, ti=c064e000 task=c05d1400 task.ti=c064e000) [ 2845.743742] Stack: [ 2845.743742] c05d1400 00000002 c05d1400 00000001 00000002 00000000 f65388dc c05d1400 [ 2845.743742] 6b6b6b6b 00000292 c064fd0c c0153732 00000000 00000000 00000001 f700fa50 [ 2845.743742] 00000046 00000000 00000000 c064fd40 c0155be6 00000000 00000002 00000001 [ 2845.743742] Call Trace: [ 2845.743742] [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0 [ 2845.743742] [<c0155be6>] ? lock_acquire+0x76/0xa0 [ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70 [ 2845.743742] [<c046c885>] ? _spin_lock_irqsave+0x45/0x80 [ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70 [ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70 [ 2845.743742] [<c03e1f94>] ? skb_queue_purge+0x14/0x20 [ 2845.743742] [<f8171f5a>] ? hci_conn_del+0x10a/0x1c0 [bluetooth] [ 2845.743742] [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap] [ 2845.743742] [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth] [ 2845.743742] [<f8175758>] ? hci_event_packet+0x5f8/0x31c0 [bluetooth] [ 2845.743742] [<c03dfe19>] ? sock_def_readable+0x59/0x80 [ 2845.743742] [<c046c14d>] ? _read_unlock+0x1d/0x20 [ 2845.743742] [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth] [ 2845.743742] [<c015388b>] ? trace_hardirqs_on+0xb/0x10 [ 2845.743742] [<f816fa6a>] ? hci_rx_task+0x2ba/0x490 [bluetooth] [ 2845.743742] [<c0133661>] ? tasklet_action+0x31/0xc0 [ 2845.743742] [<c013367c>] ? tasklet_action+0x4c/0xc0 [ 2845.743742] [<c0132eb7>] ? __do_softirq+0xa7/0x170 [ 2845.743742] [<c0116dec>] ? ack_apic_level+0x5c/0x1c0 [ 2845.743742] [<c0132fd7>] ? do_softirq+0x57/0x60 [ 2845.743742] [<c01333dc>] ? irq_exit+0x7c/0x90 [ 2845.743742] [<c01055bb>] ? do_IRQ+0x4b/0x90 [ 2845.743742] [<c01333d5>] ? irq_exit+0x75/0x90 [ 2845.743742] [<c010392c>] ? common_interrupt+0x2c/0x34 [ 2845.743742] [<c010a14f>] ? mwait_idle+0x4f/0x70 [ 2845.743742] [<c0101c05>] ? cpu_idle+0x65/0xb0 [ 2845.743742] [<c045731e>] ? rest_init+0x4e/0x60 [ 2845.743742] Code: 0f 84 69 02 00 00 83 ff 07 0f 87 1e 06 00 00 85 ff 0f 85 08 05 00 00 8b 4d cc 8b 49 04 85 c9 89 4d d4 0f 84 f7 04 00 00 8b 75 d4 <f0> ff 86 c4 00 00 00 89 f0 e8 56 a9 ff ff 85 c0 0f 85 6e 03 00 [ 2845.743742] EIP: [<c015515c>] __lock_acquire+0x6c/0xa80 SS:ESP 0068:c064fcc8 [ 2845.743742] ---[ end trace 4c985b38f022279f ]--- [ 2845.743742] Kernel panic - not syncing: Fatal exception in interrupt [ 2845.743742] ------------[ cut here ]------------ [ 2845.743742] WARNING: at kernel/smp.c:329 smp_call_function_many+0x151/0x200() [ 2845.743742] Hardware name: Dell DM051 [ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev [ 2845.743742] Pid: 0, comm: swapper Tainted: G D 2.6.29-rc5-smp #54 [ 2845.743742] Call Trace: [ 2845.743742] [<c012e076>] warn_slowpath+0x86/0xa0 [ 2845.743742] [<c015041b>] ? trace_hardirqs_off+0xb/0x10 [ 2845.743742] [<c0146384>] ? up+0x14/0x40 [ 2845.743742] [<c012e661>] ? release_console_sem+0x31/0x1e0 [ 2845.743742] [<c046c8ab>] ? _spin_lock_irqsave+0x6b/0x80 [ 2845.743742] [<c015041b>] ? trace_hardirqs_off+0xb/0x10 [ 2845.743742] [<c046c900>] ? _read_lock_irqsave+0x40/0x80 [ 2845.743742] [<c012e7f2>] ? release_console_sem+0x1c2/0x1e0 [ 2845.743742] [<c0146384>] ? up+0x14/0x40 [ 2845.743742] [<c015041b>] ? trace_hardirqs_off+0xb/0x10 [ 2845.743742] [<c046a3d7>] ? __mutex_unlock_slowpath+0x97/0x160 [ 2845.743742] [<c046a563>] ? mutex_trylock+0xb3/0x180 [ 2845.743742] [<c046a4a8>] ? mutex_unlock+0x8/0x10 [ 2845.743742] [<c015b991>] smp_call_function_many+0x151/0x200 [ 2845.743742] [<c010a1a0>] ? stop_this_cpu+0x0/0x40 [ 2845.743742] [<c015ba61>] smp_call_function+0x21/0x30 [ 2845.743742] [<c01137ae>] native_smp_send_stop+0x1e/0x50 [ 2845.743742] [<c012e0f5>] panic+0x55/0x110 [ 2845.743742] [<c01065a8>] oops_end+0xb8/0xc0 [ 2845.743742] [<c010668f>] die+0x4f/0x70 [ 2845.743742] [<c011a8c9>] do_page_fault+0x269/0x610 [ 2845.743742] [<c011a660>] ? do_page_fault+0x0/0x610 [ 2845.743742] [<c046cbaf>] error_code+0x77/0x7c [ 2845.743742] [<c015515c>] ? __lock_acquire+0x6c/0xa80 [ 2845.743742] [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0 [ 2845.743742] [<c0155be6>] lock_acquire+0x76/0xa0 [ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70 [ 2845.743742] [<c046c885>] _spin_lock_irqsave+0x45/0x80 [ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70 [ 2845.743742] [<c03e1aad>] skb_dequeue+0x1d/0x70 [ 2845.743742] [<c03e1f94>] skb_queue_purge+0x14/0x20 [ 2845.743742] [<f8171f5a>] hci_conn_del+0x10a/0x1c0 [bluetooth] [ 2845.743742] [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap] [ 2845.743742] [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth] [ 2845.743742] [<f8175758>] hci_event_packet+0x5f8/0x31c0 [bluetooth] [ 2845.743742] [<c03dfe19>] ? sock_def_readable+0x59/0x80 [ 2845.743742] [<c046c14d>] ? _read_unlock+0x1d/0x20 [ 2845.743742] [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth] [ 2845.743742] [<c015388b>] ? trace_hardirqs_on+0xb/0x10 [ 2845.743742] [<f816fa6a>] hci_rx_task+0x2ba/0x490 [bluetooth] [ 2845.743742] [<c0133661>] ? tasklet_action+0x31/0xc0 [ 2845.743742] [<c013367c>] tasklet_action+0x4c/0xc0 [ 2845.743742] [<c0132eb7>] __do_softirq+0xa7/0x170 [ 2845.743742] [<c0116dec>] ? ack_apic_level+0x5c/0x1c0 [ 2845.743742] [<c0132fd7>] do_softirq+0x57/0x60 [ 2845.743742] [<c01333dc>] irq_exit+0x7c/0x90 [ 2845.743742] [<c01055bb>] do_IRQ+0x4b/0x90 [ 2845.743742] [<c01333d5>] ? irq_exit+0x75/0x90 [ 2845.743742] [<c010392c>] common_interrupt+0x2c/0x34 [ 2845.743742] [<c010a14f>] ? mwait_idle+0x4f/0x70 [ 2845.743742] [<c0101c05>] cpu_idle+0x65/0xb0 [ 2845.743742] [<c045731e>] rest_init+0x4e/0x60 [ 2845.743742] ---[ end trace 4c985b38f02227a0 ]--- [ 2845.743742] ------------[ cut here ]------------ [ 2845.743742] WARNING: at kernel/smp.c:226 smp_call_function_single+0x8e/0x110() [ 2845.743742] Hardware name: Dell DM051 [ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev [ 2845.743742] Pid: 0, comm: swapper Tainted: G D W 2.6.29-rc5-smp #54 [ 2845.743742] Call Trace: [ 2845.743742] [<c012e076>] warn_slowpath+0x86/0xa0 [ 2845.743742] [<c012e000>] ? warn_slowpath+0x10/0xa0 [ 2845.743742] [<c015041b>] ? trace_hardirqs_off+0xb/0x10 [ 2845.743742] [<c0146384>] ? up+0x14/0x40 [ 2845.743742] [<c012e661>] ? release_console_sem+0x31/0x1e0 [ 2845.743742] [<c046c8ab>] ? _spin_lock_irqsave+0x6b/0x80 [ 2845.743742] [<c015041b>] ? trace_hardirqs_off+0xb/0x10 [ 2845.743742] [<c046c900>] ? _read_lock_irqsave+0x40/0x80 [ 2845.743742] [<c012e7f2>] ? release_console_sem+0x1c2/0x1e0 [ 2845.743742] [<c0146384>] ? up+0x14/0x40 [ 2845.743742] [<c015b7be>] smp_call_function_single+0x8e/0x110 [ 2845.743742] [<c010a1a0>] ? stop_this_cpu+0x0/0x40 [ 2845.743742] [<c026d23f>] ? cpumask_next_and+0x1f/0x40 [ 2845.743742] [<c015b95a>] smp_call_function_many+0x11a/0x200 [ 2845.743742] [<c010a1a0>] ? stop_this_cpu+0x0/0x40 [ 2845.743742] [<c015ba61>] smp_call_function+0x21/0x30 [ 2845.743742] [<c01137ae>] native_smp_send_stop+0x1e/0x50 [ 2845.743742] [<c012e0f5>] panic+0x55/0x110 [ 2845.743742] [<c01065a8>] oops_end+0xb8/0xc0 [ 2845.743742] [<c010668f>] die+0x4f/0x70 [ 2845.743742] [<c011a8c9>] do_page_fault+0x269/0x610 [ 2845.743742] [<c011a660>] ? do_page_fault+0x0/0x610 [ 2845.743742] [<c046cbaf>] error_code+0x77/0x7c [ 2845.743742] [<c015515c>] ? __lock_acquire+0x6c/0xa80 [ 2845.743742] [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0 [ 2845.743742] [<c0155be6>] lock_acquire+0x76/0xa0 [ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70 [ 2845.743742] [<c046c885>] _spin_lock_irqsave+0x45/0x80 [ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70 [ 2845.743742] [<c03e1aad>] skb_dequeue+0x1d/0x70 [ 2845.743742] [<c03e1f94>] skb_queue_purge+0x14/0x20 [ 2845.743742] [<f8171f5a>] hci_conn_del+0x10a/0x1c0 [bluetooth] [ 2845.743742] [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap] [ 2845.743742] [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth] [ 2845.743742] [<f8175758>] hci_event_packet+0x5f8/0x31c0 [bluetooth] [ 2845.743742] [<c03dfe19>] ? sock_def_readable+0x59/0x80 [ 2845.743742] [<c046c14d>] ? _read_unlock+0x1d/0x20 [ 2845.743742] [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth] [ 2845.743742] [<c015388b>] ? trace_hardirqs_on+0xb/0x10 [ 2845.743742] [<f816fa6a>] hci_rx_task+0x2ba/0x490 [bluetooth] [ 2845.743742] [<c0133661>] ? tasklet_action+0x31/0xc0 [ 2845.743742] [<c013367c>] tasklet_action+0x4c/0xc0 [ 2845.743742] [<c0132eb7>] __do_softirq+0xa7/0x170 [ 2845.743742] [<c0116dec>] ? ack_apic_level+0x5c/0x1c0 [ 2845.743742] [<c0132fd7>] do_softirq+0x57/0x60 [ 2845.743742] [<c01333dc>] irq_exit+0x7c/0x90 [ 2845.743742] [<c01055bb>] do_IRQ+0x4b/0x90 [ 2845.743742] [<c01333d5>] ? irq_exit+0x75/0x90 [ 2845.743742] [<c010392c>] common_interrupt+0x2c/0x34 [ 2845.743742] [<c010a14f>] ? mwait_idle+0x4f/0x70 [ 2845.743742] [<c0101c05>] cpu_idle+0x65/0xb0 [ 2845.743742] [<c045731e>] rest_init+0x4e/0x60 [ 2845.743742] ---[ end trace 4c985b38f02227a1 ]--- [ 2845.743742] Rebooting in 3 seconds.. My logitec bluetooth mouse trying connect to pc, but pc side reject the connection again and again. then panic happens. The reason is due to hci_conn_del_sysfs now called in hci_event_packet, the del work is done in a workqueue, so it's possible done before skb_queue_purge called. I move the hci_conn_del_sysfs after skb_queue_purge just as that before marcel's commit. Remove the hci_conn_del_sysfs in hci_conn_hash_flush as well due to hci_conn_del will deal with the work. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
96a31833 |
|
12-Feb-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Set authentication requirement before requesting it The authentication requirement got only updated when the security level increased. This is a wrong behavior. The authentication requirement is read by the Bluetooth daemon to make proper decisions when handling the IO capabilities exchange. So set the value that is currently expected by the higher layers like L2CAP and RFCOMM. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
2950f21a |
|
12-Feb-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Ask upper layers for HCI disconnect reason Some of the qualification tests demand that in case of failures in L2CAP the HCI disconnect should indicate a reason why L2CAP fails. This is a bluntly layer violation since multiple L2CAP connections could be using the same ACL and thus forcing a disconnect reason is not a good idea. To comply with the Bluetooth test specification, the disconnect reason is now stored in the L2CAP connection structure and every time a new L2CAP channel is added it will set back to its default. So only in the case where the L2CAP channel with the disconnect reason is really the last one, it will propagated to the HCI layer. The HCI layer has been extended with a disconnect indication that allows it to ask upper layers for a disconnect reason. The upper layer must not support this callback and in that case it will nicely default to the existing behavior. If an upper layer like L2CAP can provide a disconnect reason that one will be used to disconnect the ACL or SCO link. No modification to the ACL disconnect timeout have been made. So in case of Linux to Linux connection the initiator will disconnect the ACL link before the acceptor side can signal the specific disconnect reason. That is perfectly fine since Linux doesn't make use of this value anyway. The L2CAP layer has a perfect valid error code for rejecting connection due to a security violation. It is unclear why the Bluetooth specification insists on having specific HCI disconnect reason. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
657e17b0 |
|
06-Feb-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Set authentication requirements if not available When no authentication requirements are selected, but an outgoing or incoming connection has requested any kind of security enforcement, then set these authentication requirements. This ensures that the userspace always gets informed about the authentication requirements (if available). Only when no security enforcement has happened, the kernel will signal invalid requirements. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
0684e5f9 |
|
08-Feb-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Use general bonding whenever possible When receiving incoming connection to specific services, always use general bonding. This ensures that the link key gets stored and can be used for further authentications. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
efc7688b |
|
06-Feb-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Add SCO fallback for eSCO connection attempts When attempting to setup eSCO connections it can happen that some link manager implementations fail to properly negotiate the eSCO parameters and thus fail the eSCO setup. Normally the link manager is responsible for the negotiation of the parameters and actually fallback to SCO if no agreement can be reached. In cases where the link manager is just too stupid, then at least try to establish a SCO link if eSCO fails. For the Bluetooth devices with EDR support this includes handling packet types of EDR basebands. This is particular tricky since for the EDR the logic of enabling/disabling one specific packet type is turned around. This fix contains an extra bitmask to disable eSCO EDR packet when trying to fallback to a SCO connection. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
8c1b2355 |
|
15-Jan-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Add enhanced security model for Simple Pairing The current security model is based around the flags AUTH, ENCRYPT and SECURE. Starting with support for the Bluetooth 2.1 specification this is no longer sufficient. The different security levels are now defined as SDP, LOW, MEDIUM and SECURE. Previously it was possible to set each security independently, but this actually doesn't make a lot of sense. For Bluetooth the encryption depends on a previous successful authentication. Also you can only update your existing link key if you successfully created at least one before. And of course the update of link keys without having proper encryption in place is a security issue. The new security levels from the Bluetooth 2.1 specification are now used internally. All old settings are mapped to the new values and this way it ensures that old applications still work. The only limitation is that it is no longer possible to set authentication without also enabling encryption. No application should have done this anyway since this is actually a security issue. Without encryption the integrity of the authentication can't be guaranteed. As default for a new L2CAP or RFCOMM connection, the LOW security level is used. The only exception here are the service discovery sessions on PSM 1 where SDP level is used. To have similar security strength as with a Bluetooth 2.0 and before combination key, the MEDIUM level should be used. This is according to the Bluetooth specification. The MEDIUM level will not require any kind of man-in-the-middle (MITM) protection. Only the HIGH security level will require this. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
a418b893 |
|
29-Nov-2008 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Enable per-module dynamic debug messages With the introduction of CONFIG_DYNAMIC_PRINTK_DEBUG it is possible to allow debugging without having to recompile the kernel. This patch turns all BT_DBG() calls into pr_debug() to support dynamic debug messages. As a side effect all CONFIG_BT_*_DEBUG statements are now removed and some broken debug entries have been fixed. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
e7c29cb1 |
|
08-Sep-2008 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Reject L2CAP connections on an insecure ACL link The Security Mode 4 of the Bluetooth 2.1 specification has strict authentication and encryption requirements. It is the initiators job to create a secure ACL link. However in case of malicious devices, the acceptor has to make sure that the ACL is encrypted before allowing any kind of L2CAP connection. The only exception here is the PSM 1 for the service discovery protocol, because that is allowed to run on an insecure ACL link. Previously it was enough to reject a L2CAP connection during the connection setup phase, but with Bluetooth 2.1 it is forbidden to do any L2CAP protocol exchange on an insecure link (except SDP). The new hci_conn_check_link_mode() function can be used to check the integrity of an ACL link. This functions also takes care of the cases where Security Mode 4 is disabled or one of the devices is based on an older specification. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
09ab6f4c |
|
08-Sep-2008 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Enforce correct authentication requirements With the introduction of Security Mode 4 and Simple Pairing from the Bluetooth 2.1 specification it became mandatory that the initiator requires authentication and encryption before any L2CAP channel can be established. The only exception here is PSM 1 for the service discovery protocol (SDP). It is meant to be used without any encryption since it contains only public information. This is how Bluetooth 2.0 and before handle connections on PSM 1. For Bluetooth 2.1 devices the pairing procedure differentiates between no bonding, general bonding and dedicated bonding. The L2CAP layer wrongly uses always general bonding when creating new connections, but it should not do this for SDP connections. In this case the authentication requirement should be no bonding and the just-works model should be used, but in case of non-SDP connection it is required to use general bonding. If the new connection requires man-in-the-middle (MITM) protection, it also first wrongly creates an unauthenticated link key and then later on requests an upgrade to an authenticated link key to provide full MITM protection. With Simple Pairing the link key generation is an expensive operation (compared to Bluetooth 2.0 and before) and doing this twice during a connection setup causes a noticeable delay when establishing a new connection. This should be avoided to not regress from the expected Bluetooth 2.0 connection times. The authentication requirements are known up-front and so enforce them. To fulfill these requirements the hci_connect() function has been extended with an authentication requirement parameter that will be stored inside the connection information and can be retrieved by userspace at any time. This allows the correct IO capabilities exchange and results in the expected behavior. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
7d0db0a3 |
|
14-Jul-2008 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Use a more unique bus name for connections When attaching Bluetooth low-level connections to the bus, the bus name is constructed from the remote address since at that time the connection handle is not assigned yet. This has worked so far, but also caused a lot of troubles. It is better to postpone the creation of the sysfs entry to the time when the connection actually has been established and then use its connection handle as unique identifier. This also fixes the case where two different adapters try to connect to the same remote device. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
40be492f |
|
14-Jul-2008 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Export details about authentication requirements With the Simple Pairing support, the authentication requirements are an explicit setting during the bonding process. Track and enforce the requirements and allow higher layers like L2CAP and RFCOMM to increase them if needed. This patch introduces a new IOCTL that allows to query the current authentication requirements. It is also possible to detect Simple Pairing support in the kernel this way. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
769be974 |
|
14-Jul-2008 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Use ACL config stage to retrieve remote features The Bluetooth technology introduces new features on a regular basis and for some of them it is important that the hardware on both sides support them. For features like Simple Pairing it is important that the host stacks on both sides have switched this feature on. To make valid decisions, a config stage during ACL link establishment has been introduced that retrieves remote features and if needed also the remote extended features (known as remote host features) before signalling this link as connected. This change introduces full reference counting of incoming and outgoing ACL links and the Bluetooth core will disconnect both if no owner of it is present. To better handle interoperability during the pairing phase the disconnect timeout for incoming connections has been increased to 10 seconds. This is five times more than for outgoing connections. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
41a96212 |
|
14-Jul-2008 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Track status of remote Simple Pairing mode The Simple Pairing process can only be used if both sides have the support enabled in the host stack. The current Bluetooth specification has three ways to detect this support. If an Extended Inquiry Result has been sent during inquiry then it is safe to assume that Simple Pairing is enabled. It is not allowed to enable Extended Inquiry without Simple Pairing. During the remote name request phase a notification with the remote host supported features will be sent to indicate Simple Pairing support. Also the second page of the remote extended features can indicate support for Simple Pairing. For all three cases the value of remote Simple Pairing mode is stored in the inquiry cache for later use. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
e4e8e37c |
|
14-Jul-2008 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Make use of the default link policy settings The Bluetooth specification supports the default link policy settings on a per host controller basis. For every new connection the link manager would then use these settings. It is better to use this instead of bothering the controller on every connection setup to overwrite the default settings. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
a8746417 |
|
14-Jul-2008 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Track connection packet type changes The connection packet type can be changed after the connection has been established and thus needs to be properly tracked to ensure that the host stack has always correct and valid information about it. On incoming connections the Bluetooth core switches the supported packet types to the configured list for this controller. However the usefulness of this feature has been questioned a lot. The general consent is that every Bluetooth host stack should enable as many packet types as the hardware actually supports and leave the decision to the link manager software running on the Bluetooth chip. When running on Bluetooth 2.0 or later hardware, don't change the packet type for incoming connections anymore. This hardware likely supports Enhanced Data Rate and thus leave it completely up to the link manager to pick the best packet type. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
0cd63c80 |
|
18-Feb-2008 |
Dave Young <hidave.darkstar@gmail.com> |
bluetooth: put hci dev after del conn Move hci_dev_put to del_conn to avoid hci dev going away before hci conn. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
b24b8a24 |
|
23-Jan-2008 |
Pavel Emelyanov <xemul@openvz.org> |
[NET]: Convert init_timer into setup_timer Many-many code in the kernel initialized the timer->function and timer->data together with calling init_timer(timer). There is already a helper for this. Use it for networking code. The patch is HUGE, but makes the code 130 lines shorter (98 insertions(+), 228 deletions(-)). Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
38b7da09 |
|
29-Dec-2007 |
Dave Young <hidave.darkstar@gmail.com> |
[BLUETOOTH]: put_device before device_del fix Because of workqueue delay, the put_device could be called before device_del, so move it to del_conn. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
b6a0dc82 |
|
20-Oct-2007 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Add support for handling simple eSCO links With the Bluetooth 1.2 specification the Extended SCO feature for better audio connections was introduced. So far the Bluetooth core wasn't able to handle any eSCO connections correctly. This patch adds simple eSCO support while keeping backward compatibility with older devices. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
a9de9248 |
|
20-Oct-2007 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Switch from OGF+OCF to using only opcodes The Bluetooth HCI commands are divided into logical OGF groups for easier identification of their purposes. While this still makes sense for the written specification, its makes the code only more complex and harder to read. So instead of using separate OGF and OCF values to identify the commands, use a common 16-bit opcode that combines both values. As a side effect this also reduces the complexity of OGF and OCF calculations during command header parsing. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
5b7f9909 |
|
11-Jul-2007 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Add basics to better support and handle eSCO links To better support and handle eSCO links in the future a bunch of constants needs to be added and some basic routines need to be updated. This is the initial step. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
aca3192c |
|
25-Mar-2007 |
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> |
[NET] BLUETOOTH: Use cpu_to_le{16,32}() where appropriate. Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
cd354f1a |
|
14-Feb-2007 |
Tim Schmielau <tim@physik3.uni-rostock.de> |
[PATCH] remove many unneeded #includes of sched.h After Al Viro (finally) succeeded in removing the sched.h #include in module.h recently, it makes sense again to remove other superfluous sched.h includes. There are quite a lot of files which include it but don't actually need anything defined in there. Presumably these includes were once needed for macros that used to live in sched.h, but moved to other header files in the course of cleaning it up. To ease the pain, this time I did not fiddle with any header files and only removed #includes from .c-files, which tend to cause less trouble. Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha, arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig, allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all configs in arch/arm/configs on arm. I also checked that no new warnings were introduced by the patch (actually, some warnings are removed that were emitted by unnecessarily included header files). Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
8e87d142 |
|
09-Feb-2007 |
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> |
[NET] BLUETOOTH: Fix whitespace errors. Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
4c67bc74 |
|
15-Oct-2006 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Support concurrent connect requests Most Bluetooth chips don't support concurrent connect requests, because this would involve a multiple baseband page with only one radio. In the case an upper layer like L2CAP requests a concurrent connect these chips return the error "Command Disallowed" for the second request. If this happens it the responsibility of the Bluetooth core to queue the request and try again after the previous connect attempt has been completed. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
6ac59344 |
|
26-Sep-2006 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Support create connection cancel command In case of non-blocking connects it is possible that the last user of an ACL link quits before the connection has been fully established. This will lead to a race condition where the internal state of a connection is closed, but the actual link has been established and is active. In case of Bluetooth 1.2 and later devices it is possible to call create connection cancel to abort the connect. For older devices the disconnect timer will be used to trigger the needed disconnect. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
b219e3ac |
|
05-Jul-2006 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Integrate low-level connections into the driver model This patch integrates the low-level connections (ACL and SCO) into the driver model. Every connection is presented as device with the parent set to its host controller device. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
04837f64 |
|
03-Jul-2006 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Add automatic sniff mode support This patch introduces the automatic sniff mode feature. This allows the host to switch idle connections into sniff mode to safe power. Signed-off-by: Ulisses Furquim <ulissesf@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
#
6ab3d562 |
|
30-Jun-2006 |
Jörn Engel <joern@wohnheim.fh-wedel.de> |
Remove obsolete #include <linux/config.h> Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
|
#
12fe2c58 |
|
10-Jan-2006 |
Jesper Juhl <jesper.juhl@gmail.com> |
[NET]: Remove unneeded kmalloc() return value casts Get rid of needless casting of kmalloc() return value in net/ Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
5523662c |
|
25-Apr-2005 |
Al Viro <viro@parcelfarce.linux.theplanet.co.uk> |
[NET]: kill gratitious includes of major.h A lot of places in there are including major.h for no reason whatsoever. Removed. And yes, it still builds. The history of that stuff is often amusing. E.g. for net/core/sock.c the story looks so, as far as I've been able to reconstruct it: we used to need major.h in net/socket.c circa 1.1.early. In 1.1.13 that need had disappeared, along with register_chrdev(SOCKET_MAJOR, "socket", &net_fops) in sock_init(). Include had not. When 1.2 -> 1.3 reorg of net/* had moved a lot of stuff from net/socket.c to net/core/sock.c, this crap had followed... Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
b453257f |
|
25-Apr-2005 |
Al Viro <viro@www.linux.org.uk> |
[PATCH] kill gratitious includes of major.h under net/* A lot of places in there are including major.h for no reason whatsoever. Removed. And yes, it still builds. The history of that stuff is often amusing. E.g. for net/core/sock.c the story looks so, as far as I've been able to reconstruct it: we used to need major.h in net/socket.c circa 1.1.early. In 1.1.13 that need had disappeared, along with register_chrdev(SOCKET_MAJOR, "socket", &net_fops) in sock_init(). Include had not. When 1.2 -> 1.3 reorg of net/* had moved a lot of stuff from net/socket.c to net/core/sock.c, this crap had followed... Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
1da177e4 |
|
16-Apr-2005 |
Linus Torvalds <torvalds@ppc970.osdl.org> |
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
|