- 11 Apr, 2014 2 commits
-
-
Mikel Astiz authored
Do not always set the MITM protection requirement by default in the field conn->auth_type, since this will be added later in hci_io_capa_request_evt(), as part of the requirements specified in HCI_OP_IO_CAPABILITY_REPLY. This avoids a hackish exception for the auto-reject case, but doesn't change the behavior of the code at all. Signed-off-by: Mikel Astiz <mikel.astiz@bmw-carit.de> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Mikel Astiz authored
Refactor the code without changing its behavior by handling the no-bonding cases first followed by General Bonding. Signed-off-by: Mikel Astiz <mikel.astiz@bmw-carit.de> Signed-off-by: Timo Mueller <timo.mueller@bmw-carit.de> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
- 29 Mar, 2014 2 commits
-
-
Johan Hedberg authored
When sending out a device found event caused by an advertising report in the situation where we couldn't store the report as a pending one, the code was incorrectly trying to use the address and address type from the pending data. Since the pending data is cleared in the previous line this causes a potentially incorrect address type and an address of BDADDR_ANY. This patch fixes the call to use the address information correctly from the received advertising report. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Bing Zhao authored
For SD8897, CMD52 write_to_clear may have missing interrupts under certain corner case condition. Use CMD53 read-to-clear to fix the problem. Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 28 Mar, 2014 4 commits
-
-
Lukasz Rymanowski authored
To be consistent, lets use msec for this timeout as well. Note: This define value is a minimum scan time taken from BT Core spec 4.0, Vol 3, Part C, chapter 9.2.6 Signed-off-by: Lukasz Rymanowski <lukasz.rymanowski@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Lukasz Rymanowski authored
With this patch it is possible to control discovery interleaved timeout value from debugfs. It is for fine tuning of this timeout. Signed-off-by: Lukasz Rymanowski <lukasz.rymanowski@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Lukasz Rymanowski authored
Keep msec instead of jiffies in this define. This is needed by following patch where we want this timeout to be exposed in debugfs. Note: Value of this timeout comes from recommendation in BT Core Spec.4.0, Vol 3, Part C, chapter 13.2.1. Signed-off-by: Lukasz Rymanowski <lukasz.rymanowski@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Bing Zhao authored
This patch improves readability and makes future changes easier. Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 27 Mar, 2014 1 commit
-
-
Johan Hedberg authored
The ssp parameter is supposed to be a mandatory one and there are no callers that would pass NULL to this function. Removing this unnecessary NULL check also makes (false positive) static analyzer warnings go away. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 26 Mar, 2014 15 commits
-
-
Johan Hedberg authored
When sending a pending device found event triggered by disabling LE scanning we should use the stored RSSI instead of sending a zero value. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
Especially in crowded environments it can become frequent that we have to send out whatever pending event there is stored. Since user space has its own filtering of small RSSI changes sending a 0 value will essentially force user space to wake up the higher layers (e.g. over D-Bus) even though the RSSI didn't actually change more than the threshold value. This patch adds storing also of the RSSI for pending advertising reports so that we report an as accurate RSSI as possible when we have to send out the stored information to user space. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
Occasionally, during active scanning we will receive duplicate ADV_IND reports from the same device before receiving the SCAN_RSP from them. In order to not wake up user space unnecessarily it's better not to send these extra events as they do not contain any new information. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
The line was incorrectly split between the variable type and its name. This patch fixes the issue. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
All callers of hci_inquiry_cache_update() pass a non-NULL ssp pointer to it and even the function itself assumes in another place that the pointer is non-NULL. Therefore, remove the redundant check. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
To avoid too many events being sent to user space and to help parsing of all available remote device data it makes sense for us to wait for the scan response and send a single merged Device Found event to user space. This patch adds a few new variables to hci_dev to track the last received ADV_IND/ADV_SCAN_IND, i.e. those which will cause a SCAN_REQ to be send in the case of active scanning. When the SCAN_RSP is received the pending data is passed together with the SCAN_RSP to the mgmt_device_found function which takes care of merging them into a single Device Found event. We also need a bit of extra logic to handle situations where we don't receive a SCAN_RSP after caching some data. In such a scenario we simply have to send out the pending data as it is and then operate on the new report as if there was no pending data. We also need to send out any pending data when scanning stops as well as ensure that the storage is empty at the start of a new active scanning session. These both cases are covered by the update to the hci_cc_le_set_scan_enable function in this patch. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
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>
-
Johan Hedberg authored
In preparation for being able to merge ADV_IND/ADV_SCAN_IND and SCAN_RSP together into a single device found event add a second parameter to the mgmt_device_found function. For now all callers pass NULL as this parameters since we don't yet have storing of the last received advertising report. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
Passive LE scanning is only used by the kernel-internal connection establishment procedure. It makes therefore little sense to send device found events to user space. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
When a timeout occurs using directed advertising a 0x3c error gets generated. Since the operation is analogous to conventional connection creation map this to the usual EHOSTDOWN error. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
Once directed advertising is brought into the picture simply the lack of an hci_conn object when an le_conn_complete event occurs is no longer a reliable indication that the responder & initiator values need to be set based on our advertising address type. This patch moves the code for setting these values outside of the "if (!conn)" branch and ensures that they get set for any connection where we are in the slave role. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
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>
-
Andre Guedes authored
This patch does a small code simplification replacing the tipical kmalloc-copy_from_user sequence by memdup_user() helper. Cc: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
As preparation for merging ADV_IND/ADV_SCAN_IND and SCAN_RSP together into a single mgmt Device Found event refactor individual advertising report handling into a separate function. This will help keep the code more readable as more logic gets added. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
We should let user space request the peer address also in the pending connect states, i.e. BT_CONNECT and BT_CONNECT2. There is existing user space code that tries to do this and will fail without extending the set of allowed states for the peer address information. This patch adds the two states to the allowed ones in the L2CAP and RFCOMM sock_getname functions, thereby preventing ENOTCONN from being returned. Reported-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Tested-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 24 Mar, 2014 8 commits
-
-
Johan Hedberg authored
The smp variable in smp_conn_security is not used anywhere before the smp = smp_chan_create() call in the smp_conn_security function so it makes no sense to assign any other value to it before that. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
The smp pointer might not be initialized for jumps to the "done" label in the smp_conn_security function. Furthermore doing the set_bit after done might "overwrite" a previous value of the flag in case pairing was already in progress. This patch moves the call to set_bit before the label so that it is only done for a newly created smp context (as returned by smp_chan_create). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
Due to several devices being unable to handle this procedure reliably (resulting in forced disconnections before pairing completes) it's better to remove it altogether. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
In the case that the just-works model would be triggered we only want to confirm remotely initiated pairings (i.e. those triggered by a Security Request or Pairing Request). This patch adds the necessary check to the tk_request function to fall back to the JUST_WORKS method in the case of a locally initiated pairing. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
For remotely initiated just-works pairings we want to show the user a confirmation dialog for the pairing. However, we can only know which side was the initiator by tracking which side sends the first Security Request or Pairing Request PDU. This patch adds a new SMP flag to indicate whether our side was the initiator for the pairing. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
In the case that a local pairing confirmation (JUST_CFM) has been selected as the method we need to use the user confirm request mgmt event for it with the confirm_hint set to 1 (to indicate confirmation without any specific passkey value). Without this (if passkey_notify was used) the pairing would never proceed. This patch adds the necessary call to mgmt_user_confirm_request in this scenario. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
It is possible that the HCI_LE_Start_Encryption command fails in an early stage and triggers a command status event with the failure code. In such a case we need to properly notify the hci_conn object and cleanly bring the connection down. This patch adds the missing command status handler for this HCI command. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
If a sudden disconnection happens the l2cap_conn pointer may already have been cleaned up by the time hci_conn_security gets called, resulting in the following oops if we don't have a proper NULL check: BUG: unable to handle kernel NULL pointer dereference at 000000c8 IP: [<c132e2ed>] smp_conn_security+0x26/0x151 *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU: 1 PID: 673 Comm: memcheck-x86-li Not tainted 3.14.0-rc2+ #437 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: f0ef0520 ti: f0d6a000 task.ti: f0d6a000 EIP: 0060:[<c132e2ed>] EFLAGS: 00010246 CPU: 1 EIP is at smp_conn_security+0x26/0x151 EAX: f0ec1770 EBX: f0ec1770 ECX: 00000002 EDX: 00000002 ESI: 00000002 EDI: 00000000 EBP: f0d6bdc0 ESP: f0d6bda0 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 CR0: 80050033 CR2: 000000c8 CR3: 30f0f000 CR4: 00000690 Stack: f4f55000 00000002 f0d6bdcc c1097a2b c1319f40 f0ec1770 00000002 f0d6bdd0 f0d6bde8 c1312a82 f0d6bdfc c1312a82 c1319f84 00000008 f4d81c20 f0e5fd86 f0ec1770 f0d6bdfc f0d6be28 c131be3b c131bdc1 f0d25270 c131be3b 00000008 Call Trace: [<c1097a2b>] ? __kmalloc+0x118/0x128 [<c1319f40>] ? mgmt_pending_add+0x49/0x9b [<c1312a82>] hci_conn_security+0x4a/0x1dd [<c1312a82>] ? hci_conn_security+0x4a/0x1dd [<c1319f84>] ? mgmt_pending_add+0x8d/0x9b [<c131be3b>] pair_device+0x1e1/0x206 [<c131bdc1>] ? pair_device+0x167/0x206 [<c131be3b>] ? pair_device+0x1e1/0x206 [<c131ed44>] mgmt_control+0x275/0x2d6 Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 23 Mar, 2014 1 commit
-
-
Thomas Gleixner authored
Make sure no timer callback is running before releasing the datastructure which contains it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 21 Mar, 2014 2 commits
-
-
Marcel Holtmann authored
The LE scan type paramter defines if active scanning or passive scanning is in use. Track the currently set value so it can be used for decision making from other pieces in the core. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Amitkumar Karwar authored
If vendor specific HCI commands are received from application, we should send corresponding events to stack. These events should be consumed in driver, only if they are for the internal HCI commands generated by driver. This patch fixes the vendor command 0x3f stuck problem with above mentioned change. For example, hcitool cmd 3f 22 fe 06 22 21 20 43 50 00 Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 20 Mar, 2014 2 commits
-
-
Johan Hedberg authored
We need to ensure that we do not send events to user space with the identity address if we have not yet notified user space of the IRK. The code was previously trying to handle this for the mgmt_pair_device response (which worked well enough) but this is not the only connection related event that might be sent to user space before pairing is successful: another important event is Device Disconnected. The issue can actually be solved more simply than the solution previously used for mgmt_pair_device. Since we do have the identity address tracked as part of the remote IRK struct we can just copy it over from there to the hci_conn struct once we've for real sent the mgmt event for the new IRK. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
The passkey_notify and user_confirm functions in mgmt.c were expecting different endianess for the passkey, leading to a big endian bug and sparse warning in recently added SMP code. This patch converts both functions to expect host endianess and do the conversion to little endian only when assigning to the mgmt event struct. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 19 Mar, 2014 3 commits
-
-
Marcel Holtmann authored
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>
-
Johan Hedberg authored
It is possible that pairing fails after we've already received remote identity information. One example of such a situation is when re-encryption using the LTK fails. In this case the hci_conn object has already been updated with the identity address but user space does not yet know about it (since we didn't notify it of the new IRK yet). To ensure user space doesn't get a Pair Device command response with an unknown address always use the same address in the response as was used for the original command. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
When performing SMP pairing with MITM protection one side needs to enter the passkey while the other side displays to the user what needs to be entered. Nowhere in the SMP specification does it say that the displaying side needs to any kind of confirmation of the passkey, even though a code comment in smp.c implies this. This patch removes the misleading comment and converts the code to use the passkey notification mgmt event instead of the passkey confirmation mgmt event. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-