- 24 Mar, 2014 7 commits
-
-
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 5 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>
-
Johan Hedberg authored
In some cases the current 250ms delay is not enough for the remote to receive the keys, as can be witnessed by the following log: > ACL Data RX: Handle 64 flags 0x02 dlen 21 [hci1] 231.414217 SMP: Signing Information (0x0a) len 16 Signature key: 555bb66b7ab3abc9d5c287c97fe6eb29 < ACL Data TX: Handle 64 flags 0x00 dlen 21 [hci1] 231.414414 SMP: Encryption Information (0x06) len 16 Long term key: 2a7cdc233c9a4b1f3ed31dd9843fea29 < ACL Data TX: Handle 64 flags 0x00 dlen 15 [hci1] 231.414466 SMP: Master Identification (0x07) len 10 EDIV: 0xeccc Rand: 0x322e0ef50bd9308a < ACL Data TX: Handle 64 flags 0x00 dlen 21 [hci1] 231.414505 SMP: Signing Information (0x0a) len 16 Signature key: bbda1b2076e2325aa66fbcdd5388f745 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci1] 231.483130 Num handles: 1 Handle: 64 Count: 2 < HCI Command: LE Start Encryption (0x08|0x0019) plen 28 [hci1] 231.664211 Handle: 64 Random number: 0x5052ad2b75fed54b Encrypted diversifier: 0xb7c2 Long term key: a336ede66711b49a84bde9b41426692e > HCI Event: Command Status (0x0f) plen 4 [hci1] 231.666937 LE Start Encryption (0x08|0x0019) ncmd 1 Status: Success (0x00) > HCI Event: Number of Completed Packets (0x13) plen 5 [hci1] 231.712646 Num handles: 1 Handle: 64 Count: 1 > HCI Event: Disconnect Complete (0x05) plen 4 [hci1] 232.562587 Status: Success (0x00) Handle: 64 Reason: Remote User Terminated Connection (0x13) As can be seen, the last key (Signing Information) is sent at 231.414505 but the completed packets event for it comes only at 231.712646, i.e. roughly 298ms later. To have a better margin of error this patch increases the delay to 500ms. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
This is a trivial coding style simplification by instead of having an extra early return to instead revert the if condition and do the single needed queue_work() call there. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 18 Mar, 2014 3 commits
-
-
Johan Hedberg authored
The pairing process initiated through mgmt sets the conn->auth_type value regardless of BR/EDR or LE pairing. This value will contain the MITM flag if the local IO capability allows it. When sending the SMP pairing request we should check the value and ensure that the MITM bit gets correctly set in the bonding flags. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
The SMP specification is written with the assumption that both key information, plaintextData and encryptedData follow the same little endian byte ordering as the rest of SMP. Since the kernel crypto routines expect big endian data the code has had to do various byte swapping tricks to make the behavior as expected, however the swapping has been scattered all around the place. This patch centralizes the byte order swapping into the smp_e function by making its public interface match what the other SMP functions expect as per specification. The benefit is vastly simplified calls to smp_e. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
To make it possible to (correctly) pass data declared as const as the src parameter to the swap56 and swap128 functions declare this parameter also as const. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 14 Mar, 2014 1 commit
-
-
Johan Hedberg authored
When performing pairing using SMP the remote may clear any key distribution bits it wants in its pairing response. We must therefore update our local variable accordingly, otherwise we might get stuck waiting for keys that will never come. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 13 Mar, 2014 1 commit
-
-
Arnd Bergmann authored
Commit 97550887 "Bluetooth: make bluetooth 6lowpan as an option" ensures that 6LOWPAN_IPHC is turned on when we have BT_6LOWPAN enabled in Kconfig, but it allows building the IPHC code as a loadable module even if the entire Bluetooth stack is built-in, and that causes a link error. We can solve that by moving the 'select' statement into CONFIG_BT, which is a "tristate" option to enforce that 6LOWPAN_IPHC can only be a module if BT also is a module. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 12 Mar, 2014 1 commit
-
-
Joe Perches authored
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>
-
- 11 Mar, 2014 3 commits
-
-
Andre Guedes authored
To avoid flooding the host with useless advertising reports during background scan, we enable the duplicates filter from controller. However, enabling duplicates filter requires a small change in background scan routine in order to fix the following scenario: 1) Background scan is running. 2) A device disconnects and starts advertising. 3) Before host gets the disconnect event, the advertising is reported to host. Since there is no pending LE connection at that time, nothing happens. 4) Host gets the disconnection event and adds a pending connection. 5) No advertising is reported (since controller is filtering) and the connection is never established. So, to address this scenario, we should always restart background scan to unsure we don't miss any advertising report (due to duplicates filter). Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Andrew Earl authored
Add additional error case to attempt alternative configuration for SCO. Error occurs with Intel BT controller where fallback is not attempted as the error 0x20 Unsupported LMP Parameter value is not included in the list of errors where a retry should be attempted. The problem also affects PTS test case TC_HF_ACS_BV_05_I. See the HCI log below for details: < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17 handle 256 voice setting 0x0060 ptype 0x0380 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 > HCI Event: Max Slots Change (0x1b) plen 3 handle 256 slots 1 > HCI Event: Synchronous Connect Complete (0x2c) plen 17 status 0x20 handle 0 bdaddr 00:80:98:09:0B:19 type eSCO Error: Unsupported LMP Parameter Value < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17 handle 256 voice setting 0x0060 ptype 0x0380 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 > HCI Event: Max Slots Change (0x1b) plen 3 handle 256 slots 5 > HCI Event: Synchronous Connect Complete (0x2c) plen 17 status 0x20 handle 0 bdaddr 00:80:98:09:0B:19 type eSCO Error: Unsupported LMP Parameter Value < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17 handle 256 voice setting 0x0060 ptype 0x03c8 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 > HCI Event: Max Slots Change (0x1b) plen 3 handle 256 slots 1 > HCI Event: Synchronous Connect Complete (0x2c) plen 17 status 0x00 handle 257 bdaddr 00:80:98:09:0B:19 type eSCO Air mode: CVSD See btmon log for further details: > HCI Event (0x0f) plen 4 [hci0] 44.888063 Setup Synchronous Connection (0x01|0x0028) ncmd 1 Status: Success (0x00) > HCI Event (0x1b) plen 3 [hci0] 44.893064 Handle: 256 Max slots: 1 > HCI Event (0x2c) plen 17 [hci0] 44.942080 Status: Unsupported LMP Parameter Value (0x20) Handle: 0 Address: 00:1B:DC:06:04:B0 (OUI 00-1B-DC) Link type: eSCO (0x02) Transmission interval: 0x00 Retransmission window: 0x01 RX packet length: 0 TX packet length: 0 Air mode: CVSD (0x02) > HCI Event (0x1b) plen 3 [hci0] 44.948054 Handle: 256 Max slots: 5 Signed-off-by: Andrew Earl <andrewx.earl@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Alexander Aring authored
Currently you can have bluetooth 6lowpan without ipv6 enabled. This doesn't make any sense. With this patch you can disable/enable bluetooth 6lowpan support at compile time. The current bluetooth 6lowpan implementation doesn't check the return value of 6lowpan function. Nevertheless I added -EOPNOTSUPP as return value if 6lowpan bluetooth is disabled. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 10 Mar, 2014 1 commit
-
-
Marcel Holtmann authored
In case the pairable option has been disabled, the pairing procedure does not create keys for bonding. This means that these generated keys should not be stored persistently. For LTK and CSRK this is important to tell userspace to not store these new keys. They will be available for the lifetime of the device, but after the next power cycle they should not be used anymore. Inform userspace to actually store the keys persistently only if both sides request bonding. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
- 09 Mar, 2014 1 commit
-
-
Marcel Holtmann authored
The connection signature resolving key (CSRK) is used for attribute protocol signed write procedures. This change generates a new local key during pairing and requests the peer key as well. Newly generated key and received key will be provided to userspace using the New Signature Resolving Key management event. The Master CSRK can be used for verification of remote signed write PDUs and the Slave CSRK can be used for sending signed write PDUs to the remote device. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
- 07 Mar, 2014 3 commits
-
-
Gustavo Padovan authored
vtable's method alloc_skb() needs to return a ERR_PTR in case of err and not a NULL. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Peng Chen authored
The version is always in little endian format. This patch makes the driver work on both little and big endian CPUs. Signed-off-by: Peng Chen <pengchen@qca.qualcomm.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Johan Hedberg authored
The debug logs for reporting a discrepancy between the expected amount of keys and the actually received amount of keys got these value mixed up. This patch fixes the issue. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 05 Mar, 2014 3 commits
-
-
Peng Chen authored
usb devices info: T: Bus=06 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 13 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=e005 Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Peng Chen <pengchen@qca.qualcomm.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Valentin Ilie authored
Remove assignment in if-statements to be consistent with the coding style. Signed-off-by: Valentin Ilie <valentin.ilie@gmail.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Claudio Takahasi authored
This patch fixes authentication failure on LE link re-connection when BlueZ acts as slave (peripheral). LTK is removed from the internal list after its first use causing PIN or Key missing reply when re-connecting the link. The LE Long Term Key Request event indicates that the master is attempting to encrypt or re-encrypt the link. Pre-condition: BlueZ host paired and running as slave. How to reproduce(master): 1) Establish an ACL LE encrypted link 2) Disconnect the link 3) Try to re-establish the ACL LE encrypted link (fails) > HCI Event: LE Meta Event (0x3e) plen 19 LE Connection Complete (0x01) Status: Success (0x00) Handle: 64 Role: Slave (0x01) ... @ Device Connected: 00:02:72:DC:29:C9 (1) flags 0x0000 > HCI Event: LE Meta Event (0x3e) plen 13 LE Long Term Key Request (0x05) Handle: 64 Random number: 875be18439d9aa37 Encryption diversifier: 0x76ed < HCI Command: LE Long Term Key Request Reply (0x08|0x001a) plen 18 Handle: 64 Long term key: 2aa531db2fce9f00a0569c7d23d17409 > HCI Event: Command Complete (0x0e) plen 6 LE Long Term Key Request Reply (0x08|0x001a) ncmd 1 Status: Success (0x00) Handle: 64 > HCI Event: Encryption Change (0x08) plen 4 Status: Success (0x00) Handle: 64 Encryption: Enabled with AES-CCM (0x01) ... @ Device Disconnected: 00:02:72:DC:29:C9 (1) reason 3 < HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1 Advertising: Enabled (0x01) > HCI Event: Command Complete (0x0e) plen 4 LE Set Advertise Enable (0x08|0x000a) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 19 LE Connection Complete (0x01) Status: Success (0x00) Handle: 64 Role: Slave (0x01) ... @ Device Connected: 00:02:72:DC:29:C9 (1) flags 0x0000 > HCI Event: LE Meta Event (0x3e) plen 13 LE Long Term Key Request (0x05) Handle: 64 Random number: 875be18439d9aa37 Encryption diversifier: 0x76ed < HCI Command: LE Long Term Key Request Neg Reply (0x08|0x001b) plen 2 Handle: 64 > HCI Event: Command Complete (0x0e) plen 6 LE Long Term Key Request Neg Reply (0x08|0x001b) ncmd 1 Status: Success (0x00) Handle: 64 > HCI Event: Disconnect Complete (0x05) plen 4 Status: Success (0x00) Handle: 64 Reason: Authentication Failure (0x05) @ Device Disconnected: 00:02:72:DC:29:C9 (1) reason 0 Signed-off-by: Claudio Takahasi <claudio.takahasi@openbossa.org> Cc: stable@vger.kernel.org Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
- 04 Mar, 2014 1 commit
-
-
Michael Knudsen authored
When stopping BCSP/H5, stop the retransmission timer before proceeding to clean up packet queues. The previous code had a race condition where the timer could trigger after the packet lists and protocol structure had been removed which led to dereferencing NULL or use-after-free bugs. Signed-off-by: Michael Knudsen <m.knudsen@samsung.com> Reported-by: Kirill Tkhai <ktkhai@parallels.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
- 28 Feb, 2014 5 commits
-
-
Johan Hedberg authored
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>
-
Johan Hedberg authored
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>
-
Johan Hedberg authored
Some devices may refuse to re-encrypt with the LTK if they haven't received all our keys yet. This patch adds a 250ms delay before attempting re-encryption with the LTK. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
It's not strictly speaking required to re-encrypt a link once we receive an LTK since the connection is already encrypted with the STK. However, re-encrypting with the LTK allows us to verify that we've received an LTK that actually works. This patch updates the SMP code to request encrypting with the LTK in case we're in master role and waits until the key refresh complete event before notifying user space of the distributed keys. A new flag is also added for the SMP context to ensure that we re-encryption only once in case of multiple calls to smp_distribute_keys. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
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>
-