An error occurred fetching the project authors.
  1. 13 Jun, 2014 2 commits
    • Johan Hedberg's avatar
      Bluetooth: Add clarifying comment for conn->auth_type · 4ad51a75
      Johan Hedberg authored
      When responding to an IO capability request when we're the initiators of
      the pairing we will not yet have the remote IO capability information.
      Since the conn->auth_type variable is treated as an "absolute"
      requirement instead of a hint of what's needed later in the user
      confirmation request handler it's important that it doesn't have the
      MITM bit set if there's any chance that the remote device doesn't have
      the necessary IO capabilities.
      
      This patch adds a clarifying comment so that conn->auth_type is left
      untouched in this scenario.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      4ad51a75
    • Johan Hedberg's avatar
      Bluetooth: Fix SSP acceptor just-works confirmation without MITM · ba15a58b
      Johan Hedberg authored
      From the Bluetooth Core Specification 4.1 page 1958:
      
      "if both devices have set the Authentication_Requirements parameter to
      one of the MITM Protection Not Required options, authentication stage 1
      shall function as if both devices set their IO capabilities to
      DisplayOnly (e.g., Numeric comparison with automatic confirmation on
      both devices)"
      
      So far our implementation has done user confirmation for all just-works
      cases regardless of the MITM requirements, however following the
      specification to the word means that we should not be doing confirmation
      when neither side has the MITM flag set.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Tested-by: default avatarSzymon Janc <szymon.janc@tieto.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org
      ba15a58b
  2. 02 Jun, 2014 1 commit
  3. 31 May, 2014 1 commit
  4. 16 May, 2014 1 commit
  5. 09 May, 2014 1 commit
  6. 08 May, 2014 1 commit
  7. 25 Apr, 2014 1 commit
  8. 18 Apr, 2014 1 commit
  9. 11 Apr, 2014 4 commits
    • Mikel Astiz's avatar
      Bluetooth: Request MITM Protection when initiator · b16c6604
      Mikel Astiz authored
      The GAP Specification gives the flexibility to decide whether MITM
      Protection is requested or not (Bluetooth Core Specification v4.0
      Volume 3, part C, section 6.5.3) when replying to an
      HCI_EV_IO_CAPA_REQUEST event.
      
      The recommendation is *not* to set this flag "unless the security
      policy of an available local service requires MITM Protection"
      (regardless of the bonding type). However, the kernel doesn't
      necessarily have this information and therefore the safest choice is
      to always use MITM Protection, also for General Bonding.
      
      This patch changes the behavior for the General Bonding initiator
      role, always requesting MITM Protection even if no high security level
      is used. Depending on the remote capabilities, the protection might
      not be actually used, and we will accept this locally unless of course
      a high security level was originally required.
      
      Note that this was already done for Dedicated Bonding. No-Bonding is
      left unmodified because MITM Protection is normally not desired in
      these cases.
      Signed-off-by: default avatarMikel Astiz <mikel.astiz@bmw-carit.de>
      Signed-off-by: default avatarTimo Mueller <timo.mueller@bmw-carit.de>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      b16c6604
    • Timo Mueller's avatar
      Bluetooth: Use MITM Protection when IO caps allow it · 7e74170a
      Timo Mueller authored
      When responding to a remotely-initiated pairing procedure, a MITM
      protected SSP associaton model can be used for pairing if both local
      and remote IO capabilities are set to something other than
      NoInputNoOutput, regardless of the bonding type (Dedicated or
      General).
      
      This was already done for Dedicated Bonding but this patch proposes to
      use the same policy for General Bonding as well.
      
      The GAP Specification gives the flexibility to decide whether MITM
      Protection is used ot not (Bluetooth Core Specification v4.0 Volume 3,
      part C, section 6.5.3).
      
      Note however that the recommendation is *not* to set this flag "unless
      the security policy of an available local service requires MITM
      Protection" (for both Dedicated and General Bonding). However, as we are
      already requiring MITM for Dedicated Bonding, we will follow this
      behaviour also for General Bonding.
      Signed-off-by: default avatarTimo Mueller <timo.mueller@bmw-carit.de>
      Signed-off-by: default avatarMikel Astiz <mikel.astiz@bmw-carit.de>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      7e74170a
    • Mikel Astiz's avatar
      Bluetooth: Refactor code for outgoing dedicated bonding · 6fd6b915
      Mikel Astiz authored
      Do not always set the MITM protection requirement by default in the
      field conn->auth_type, since this will be added later in
      hci_io_capa_request_evt(), as part of the requirements specified in
      HCI_OP_IO_CAPABILITY_REPLY.
      
      This avoids a hackish exception for the auto-reject case, but doesn't
      change the behavior of the code at all.
      Signed-off-by: default avatarMikel Astiz <mikel.astiz@bmw-carit.de>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      6fd6b915
    • Mikel Astiz's avatar
      Bluetooth: Refactor hci_get_auth_req() · b7f94c88
      Mikel Astiz authored
      Refactor the code without changing its behavior by handling the
      no-bonding cases first followed by General Bonding.
      Signed-off-by: default avatarMikel Astiz <mikel.astiz@bmw-carit.de>
      Signed-off-by: default avatarTimo Mueller <timo.mueller@bmw-carit.de>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      b7f94c88
  10. 29 Mar, 2014 1 commit
  11. 26 Mar, 2014 10 commits
  12. 24 Mar, 2014 1 commit
  13. 21 Mar, 2014 1 commit
  14. 20 Mar, 2014 1 commit
  15. 19 Mar, 2014 1 commit
  16. 12 Mar, 2014 1 commit
  17. 11 Mar, 2014 1 commit
    • 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
  18. 05 Mar, 2014 1 commit
    • 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
  19. 28 Feb, 2014 6 commits
  20. 27 Feb, 2014 3 commits