1. 26 Mar, 2014 15 commits
  2. 24 Mar, 2014 8 commits
  3. 23 Mar, 2014 1 commit
  4. 21 Mar, 2014 2 commits
  5. 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
  6. 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
  7. 18 Mar, 2014 3 commits
  8. 14 Mar, 2014 1 commit
  9. 13 Mar, 2014 1 commit
  10. 12 Mar, 2014 1 commit
  11. 11 Mar, 2014 1 commit
    • 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