1. 24 3月, 2014 4 次提交
    • J
      Bluetooth: Fix SMP confirmation callback handling · 4eb65e66
      Johan Hedberg 提交于
      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: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      4eb65e66
    • J
      Bluetooth: Add missing cmd_status handler for LE_Start_Encryption · 81d0c8ad
      Johan Hedberg 提交于
      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: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      81d0c8ad
    • J
      Bluetooth: Fix potential NULL pointer dereference in SMP · 0a66cf20
      Johan Hedberg 提交于
      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: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0a66cf20
    • T
      Bluetooth: bluecard: Use del_timer_sync() in teardown path · d8ff9cdf
      Thomas Gleixner 提交于
      Make sure no timer callback is running before releasing the
      datastructure which contains it.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      d8ff9cdf
  2. 22 3月, 2014 1 次提交
  3. 21 3月, 2014 2 次提交
  4. 20 3月, 2014 6 次提交
    • J
      Bluetooth: Fix passkey endianess in user_confirm and notify_passkey · 39adbffe
      Johan Hedberg 提交于
      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: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      39adbffe
    • M
      Bluetooth: Enforce strict Secure Connections Only mode security · 40b552aa
      Marcel Holtmann 提交于
      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: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      40b552aa
    • J
      Bluetooth: Fix Pair Device response parameters for pairing failure · 4e7b2030
      Johan Hedberg 提交于
      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: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      4e7b2030
    • J
      Bluetooth: Fix SMP user passkey notification mgmt event · 01ad34d2
      Johan Hedberg 提交于
      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: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      01ad34d2
    • J
      Bluetooth: Increase SMP re-encryption delay to 500ms · 5ed884d7
      Johan Hedberg 提交于
      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: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      5ed884d7
    • J
      Bluetooth: Simplify logic when checking SMP_FLAG_TK_VALID · 18e4aeb9
      Johan Hedberg 提交于
      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: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      18e4aeb9
  5. 19 3月, 2014 3 次提交
  6. 15 3月, 2014 1 次提交
  7. 13 3月, 2014 2 次提交
  8. 12 3月, 2014 1 次提交
    • A
      Bluetooth: Enable duplicates filter in background scan · 4340a124
      Andre Guedes 提交于
      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: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      4340a124
  9. 11 3月, 2014 2 次提交
    • A
      Bluetooth: Fix aborting eSCO connection in case of error 0x20 · 27539bc4
      Andrew Earl 提交于
      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: NAndrew Earl <andrewx.earl@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      27539bc4
    • A
      Bluetooth: make bluetooth 6lowpan as an option · 97550887
      Alexander Aring 提交于
      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: NAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      97550887
  10. 10 3月, 2014 2 次提交
  11. 08 3月, 2014 3 次提交
  12. 06 3月, 2014 3 次提交
    • P
      Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012. · ca58e594
      Peng Chen 提交于
      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: NPeng Chen <pengchen@qca.qualcomm.com>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      ca58e594
    • V
      Bluetooth: Remove assignments in if-statements · a08b15e6
      Valentin Ilie 提交于
      Remove assignment in if-statements to be consistent with the coding
      style.
      Signed-off-by: NValentin Ilie <valentin.ilie@gmail.com>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      a08b15e6
    • C
      Bluetooth: Fix removing Long Term Key · 5981a882
      Claudio Takahasi 提交于
      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: NClaudio Takahasi <claudio.takahasi@openbossa.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      5981a882
  13. 04 3月, 2014 1 次提交
  14. 01 3月, 2014 4 次提交
  15. 28 2月, 2014 5 次提交