summaryrefslogtreecommitdiffstats
path: root/net (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'for-upstream' of ↵John W. Linville2014-03-276-77/+106
|\ | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
| * Bluetooth: Fix returning peer address in pending connect stateJohan Hedberg2014-03-262-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Remove unnecessary assignment in SMPJohan Hedberg2014-03-241-2/+0
| | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Fix potential NULL pointer dereference in smp_conn_securityJohan Hedberg2014-03-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Remove LTK re-encryption procedureJohan Hedberg2014-03-242-49/+7
| | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Don't try to confirm locally initiated SMP pairingJohan Hedberg2014-03-241-0/+5
| | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Add SMP flag to track which side is the initiatorJohan Hedberg2014-03-242-0/+7
| | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Fix SMP confirmation callback handlingJohan Hedberg2014-03-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Add missing cmd_status handler for LE_Start_EncryptionJohan Hedberg2014-03-241-0/+34
| | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Fix potential NULL pointer dereference in SMPJohan Hedberg2014-03-241-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Track current configured LE scan type parameterMarcel Holtmann2014-03-211-0/+25
| | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Fix address value for early disconnection eventsJohan Hedberg2014-03-202-21/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Fix passkey endianess in user_confirm and notify_passkeyJohan Hedberg2014-03-203-5/+5
| | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'for-upstream' of ↵John W. Linville2014-03-2015-183/+360
|\| | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
| * Bluetooth: Enforce strict Secure Connections Only mode securityMarcel Holtmann2014-03-192-0/+23
| | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Fix Pair Device response parameters for pairing failureJohan Hedberg2014-03-191-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Fix SMP user passkey notification mgmt eventJohan Hedberg2014-03-191-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Increase SMP re-encryption delay to 500msJohan Hedberg2014-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Simplify logic when checking SMP_FLAG_TK_VALIDJohan Hedberg2014-03-191-4/+2
| | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Fix MITM flag when initiating SMP pairingJohan Hedberg2014-03-181-0/+6
| | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Fix smp_e byte order to be consistent with SMP specificationJohan Hedberg2014-03-181-55/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Fix const declaration for swap function src parameterJohan Hedberg2014-03-181-2/+2
| | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Fix updating SMP remote key distribution informationJohan Hedberg2014-03-141-0/+5
| | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: make sure 6LOWPAN_IPHC is built-in if neededArnd Bergmann2014-03-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 975508879 "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>
| * Bluetooth: Convert uses of __constant_<foo> to <foo>Joe Perches2014-03-1211-96/+96
| | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Enable duplicates filter in background scanAndre Guedes2014-03-111-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Fix aborting eSCO connection in case of error 0x20Andrew Earl2014-03-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: make bluetooth 6lowpan as an optionAlexander Aring2014-03-113-2/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Make LTK and CSRK only persisent when bondingMarcel Holtmann2014-03-102-8/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Add support for handling signature resolving keysMarcel Holtmann2014-03-093-5/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Fix skb allocation check for A2MPGustavo Padovan2014-03-071-1/+7
| | | | | | | | | | | | | | | | 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>
| * Bluetooth: Fix expected key count debug logsJohan Hedberg2014-03-071-3/+3
| | | | | | | | | | | | | | | | | | 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>
| * Bluetooth: Fix removing Long Term KeyClaudio Takahasi2014-03-051-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'for-john' of ↵John W. Linville2014-03-2022-176/+298
|\ \ | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
| * | cfg80211: remove macro ASSERT_RDEV_LOCK(rdev)Zhao, Gang2014-03-194-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | Macro ASSERT_RDEV_LOCK(rdev) is equal to ASSERT_RTNL(), so replace it with ASSERT_RTNL() and remove it. Signed-off-by: Zhao, Gang <gamerh2o@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | cfg80211: remove unnecessary checkZhao, Gang2014-03-191-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RCU pointer bss->pub.beacon_ies is checked before in previous statement: if (rcu_access_pointer(bss->pub.beacon_ies)) continue; There is no need to check it twice(and in the wrong way :) ). Signed-off-by: Zhao, Gang <gamerh2o@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | mac80211: set beamforming bit in radiotapEmmanuel Grumbach2014-03-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add a bit in rx_status.vht_flags to let the low level driver notify mac80211 about a beamformed packet. Propagate this to the radiotap header. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | cfg80211/mac80211: ignore signal if the frame was heard on wrong channelEmmanuel Grumbach2014-03-193-29/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On 2.4Ghz band, the channels overlap since the delta between different channels is 5Mhz while the width of the receiver is 20Mhz (at least). This means that we can hear beacons or probe responses from adjacent channels. These frames will have a significant lower RSSI which will feed all kinds of logic with inaccurate data. An obvious example is the roaming algorithm that will think our AP is getting weak and will try to move to another AP. In order to avoid this, update the signal only if the frame has been heard on the same channel as the one advertised by the AP in its DS / HT IEs. We refrain from updating the values only if the AP is already in the BSS list so that we will still have a valid (but inaccurate) value if the AP was heard on an adjacent channel only. To achieve this, stop taking the channel from DS / HT IEs in mac80211. The DS / HT IEs is taken into account to discard the frame if it was received on a disabled channel. This can happen due to the same phenomenon: the frame is sent on channel 12, but heard on channel 11 while channel 12 can be disabled on certain devices. Since this check is done in cfg80211, stop even checking this in mac80211. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> [remove unused rx_freq variable] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | cfg80211: make __cfg80211_join_ibss() staticZhao, Gang2014-03-192-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | Function __cfg80211_join_ibss() is only used in net/wireless/ibss.c, so make it static. Signed-off-by: Zhao, Gang <gamerh2o@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | mac80211: release sched_scan_sdata when stopping sched scanAlexander Bondar2014-03-191-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Assuming sched_scan_stop operation is synchronous the driver may not necessary call ieee80211_sched_scan_stopped_work. Since this work is the only place where sched_scan_sdata is released we can possibly run into situation when it is never released. Fix this by releasing it just after calling drv_sched_scan_stop. Signed-off-by: Alexander Bondar <alexander.bondar@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | mac80211: fix WPA with VLAN on AP side with ps-sta againMichael Braun2014-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit de74a1d9032f4d37ea453ad2a647e1aff4cd2591 "mac80211: fix WPA with VLAN on AP side with ps-sta" fixed an issue where queued multicast packets would be sent out encrypted with the key of an other bss. commit "7cbf9d017dbb5e3276de7d527925d42d4c11e732" "mac80211: fix oops on mesh PS broadcast forwarding" essentially reverted it, because vif.type cannot be AP_VLAN due to the check to vif.type in ieee80211_get_buffered_bc before. As the later commit intended to fix the MESH case, fix it by checking for IFTYPE_AP instead of IFTYPE_AP_VLAN. Cc: stable@vger.kernel.org Fixes: 7cbf9d017dbb ("mac80211: fix oops on mesh PS broadcast forwarding") Signed-off-by: Michael Braun <michael-dev@fami-braun.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | mac80211: fix suspend vs. authentication raceJohannes Berg2014-03-193-3/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since Stanislaw's patch removing the quiescing code, mac80211 had a race regarding suspend vs. authentication: as cfg80211 doesn't track authentication attempts, it can't abort them. Therefore the attempts may be kept running while suspending, which can lead to all kinds of issues, in at least some cases causing an error in iwlmvm firmware. Fix this by aborting the authentication attempt when suspending. Cc: stable@vger.kernel.org Fixes: 12e7f517029d ("mac80211: cleanup generic suspend/resume procedures") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | mac80211: verify deauthentication and return error on failureJohannes Berg2014-03-191-13/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When still authenticating the mac80211 code handling a deauthentication requests from userspace doesn't verify that the request is valid in any way, fix that. Additionally, it never returns an error, even if there's no connection or authentication attempt, fix that as well. While at it, move the message to not print a message in the error case and to distinguish between the two cases. Also simplify the code by duplicating the cfg80211 call. Reviewed-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | mac80211: fix potential use-after-freeJohannes Berg2014-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The bss struct might be freed in ieee80211_rx_bss_put(), so we shouldn't use it afterwards. Cc: stable@vger.kernel.org (3.10+) Fixes: 817cee7675237 ("mac80211: track AP's beacon rate and give it to the driver") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | cfg80211: allow reprocessing of pending requestsLuis R. Rodriguez2014-03-031-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In certain situations we want to trigger reprocessing of the last regulatory hint. One situation in which this makes sense is the case where the cfg80211 was built-in to the kernel, CFG80211_INTERNAL_REGDB was not enabled and the CRDA binary is on a partition not availble during early boot. In such a case we want to be able to re-process the same request at some other point. When we are asked to re-process the same request we need to be careful to not kfree it, addresses that. Reported-by: Sander Eikelenboom <linux@eikelenboom.it> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> [rename function] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | mac80211: add missing update on rx status VHT flagChun-Yeow Yeoh2014-03-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add missing update on the rx status vht flag of the last data packet. Otherwise, cfg80211_calculate_bitrate_vht may not consider the channel width resulting in wrong calculation of the received bitrate. Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | mac80211: refactor channel switch functionMichal Kazior2014-03-031-50/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | The function was quite big. This splits out beacon updating into a separate function for improved maintenance and extension. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | cfg80211: send stop AP event only due to internal reasonIlan Peer2014-02-255-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit "nl80211: send event when AP operation is stopped" added an event to notify user space that an AP interface has been stopped, to handle cases such as suspend etc. The event is sent regardless if the stop AP flow was triggered by user space or due to internal state change. This might cause issues with wpa_supplicant/hostapd flows that consider stop AP flow as a synchronous one, e.g., AP/GO channel change in the absence of CSA support. In such cases, the flow will restart the AP immediately after the stop AP flow is done, and only handle the stop AP event after the current flow is done, and as a result stop the AP again. Change the current implementation to only send the event in case the stop AP was triggered due to an internal reason. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | cfg80211: DFS get CAC time from regulatory databaseJanusz Dziedzic2014-02-255-6/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | Send Channel Availability Check time as a parameter of start_radar_detection() callback. Get CAC time from regulatory database. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | cfg80211: regulatory: allow getting DFS CAC time from userspaceJanusz Dziedzic2014-02-253-8/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce DFS CAC time as a regd param, configured per REG_RULE and set per channel in cfg80211. DFS CAC time is close connected with regulatory database configuration. Instead of using hardcoded values, get DFS CAC time form regulatory database. Pass DFS CAC time to user mode (mainly for iw reg get, iw list, iw info). Allow setting DFS CAC time via CRDA. Add support for internal regulatory database. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> [rewrap commit log] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-17 22:49:36 +0100