1. 24 Mar, 2014 7 commits
  2. 23 Mar, 2014 1 commit
  3. 21 Mar, 2014 2 commits
  4. 20 Mar, 2014 2 commits
    • Johan Hedberg's avatar
      Bluetooth: Fix address value for early disconnection events · 61b1a7fb
      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: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      61b1a7fb
    • Johan Hedberg's avatar
      Bluetooth: Fix passkey endianess in user_confirm and notify_passkey · 39adbffe
      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: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      39adbffe
  5. 19 Mar, 2014 5 commits
    • Marcel Holtmann's avatar
      Bluetooth: Enforce strict Secure Connections Only mode security · 40b552aa
      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: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      40b552aa
    • Johan Hedberg's avatar
      Bluetooth: Fix Pair Device response parameters for pairing failure · 4e7b2030
      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: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      4e7b2030
    • Johan Hedberg's avatar
      Bluetooth: Fix SMP user passkey notification mgmt event · 01ad34d2
      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: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      01ad34d2
    • Johan Hedberg's avatar
      Bluetooth: Increase SMP re-encryption delay to 500ms · 5ed884d7
      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: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      5ed884d7
    • Johan Hedberg's avatar
      Bluetooth: Simplify logic when checking SMP_FLAG_TK_VALID · 18e4aeb9
      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: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      18e4aeb9
  6. 18 Mar, 2014 3 commits
  7. 14 Mar, 2014 1 commit
  8. 13 Mar, 2014 1 commit
  9. 12 Mar, 2014 1 commit
  10. 11 Mar, 2014 3 commits
    • Andre Guedes's avatar
      Bluetooth: Enable duplicates filter in background scan · 4340a124
      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: default avatarAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      4340a124
    • Andrew Earl's avatar
      Bluetooth: Fix aborting eSCO connection in case of error 0x20 · 27539bc4
      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: default avatarAndrew Earl <andrewx.earl@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      27539bc4
    • Alexander Aring's avatar
      Bluetooth: make bluetooth 6lowpan as an option · 97550887
      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: default avatarAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      97550887
  11. 10 Mar, 2014 1 commit
  12. 09 Mar, 2014 1 commit
  13. 07 Mar, 2014 3 commits
  14. 05 Mar, 2014 3 commits
    • Peng Chen's avatar
      Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012. · ca58e594
      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: default avatarPeng Chen <pengchen@qca.qualcomm.com>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      ca58e594
    • Valentin Ilie's avatar
      Bluetooth: Remove assignments in if-statements · a08b15e6
      Valentin Ilie authored
      Remove assignment in if-statements to be consistent with the coding
      style.
      Signed-off-by: default avatarValentin Ilie <valentin.ilie@gmail.com>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      a08b15e6
    • Claudio Takahasi's avatar
      Bluetooth: Fix removing Long Term Key · 5981a882
      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: default avatarClaudio Takahasi <claudio.takahasi@openbossa.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      5981a882
  15. 04 Mar, 2014 1 commit
  16. 28 Feb, 2014 5 commits