1. 20 3月, 2014 2 次提交
  2. 13 3月, 2014 1 次提交
  3. 10 3月, 2014 2 次提交
  4. 08 3月, 2014 1 次提交
  5. 28 2月, 2014 5 次提交
    • J
      Bluetooth: Add protections for updating local random address · 8d97250e
      Johan Hedberg 提交于
      Different controllers behave differently when HCI_Set_Random_Address is
      called while they are advertising or have a HCI_LE_Create_Connection in
      progress. Some take the newly written address into use for the pending
      operation while others use the random address that we had at the time
      that the operation started.
      
      Due to this undefined behavior and for the fact that we want to reliably
      determine the initiator address of all connections for the sake of SMP
      it's best to simply prevent the random address update if we have these
      problematic operations in progress.
      
      This patch adds a set_random_addr() helper function for the use of
      hci_update_random_address which contains the necessary checks for
      advertising and ongoing LE connections.
      
      One extra thing we need to do is to clear the HCI_ADVERTISING flag in
      the enable_advertising() function before sending any commands. Since
      re-enabling advertising happens by calling first disable_advertising()
      and then enable_advertising() all while having the HCI_ADVERTISING flag
      set. Clearing the flag lets the set_random_addr() function know that
      it's safe to write a new address at least as far as advertising is
      concerned.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8d97250e
    • M
      Bluetooth: Use __le64 type for LE random numbers · fe39c7b2
      Marcel Holtmann 提交于
      The random numbers in Bluetooth Low Energy are 64-bit numbers and should
      also be little endian since the HCI specification is little endian.
      
      Change the whole Low Energy pairing to use __le64 instead of a byte
      array.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      fe39c7b2
    • J
      Bluetooth: Add timer to force power off · a3172b7e
      Johan Hedberg 提交于
      If some of the cleanup commands caused by mgmt_set_powered(off) never
      complete we should still force the adapter to be powered down. This is
      rather easy to do since hdev->power_off is already a delayed work
      struct. This patch schedules this delayed work if at least one HCI
      command was sent by the cleanup procedure.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a3172b7e
    • J
      Bluetooth: Fix disconnecting connections in non-connected states · c9910d0f
      Johan Hedberg 提交于
      When powering off and disconnecting devices we should also consider
      connections which have not yet reached the BT_CONNECTED state. They may
      not have a valid handle yet and simply sending a HCI_Disconnect will not
      work.
      
      This patch updates the code to either disconnect, cancel connection
      creation or reject incoming connection creation based on the current
      conn->state value as well as the link type in question.
      
      When the power off procedure results in canceling connection attempts
      instead of disconnecting connections we get a connection failed event
      instead of a disconnection event. Therefore, we also need to have extra
      code in the mgmt_connect_failed function to check if we should proceed
      with the power off or not.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      c9910d0f
    • L
      Bluetooth: Fix response on confirm_name · d3a2541d
      Lukasz Rymanowski 提交于
      According to mgmt-api.txt, in case of confirm name command,
      cmd_complete should be always use as a response. Not command status
      as it is now for failures.
      Using command complete on failure is actually better as client might
      be interested in device address for which confirm name failed.
      Signed-off-by: NLukasz Rymanowski <lukasz.rymanowski@tieto.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      d3a2541d
  6. 27 2月, 2014 7 次提交
  7. 26 2月, 2014 1 次提交
    • J
      Bluetooth: Fix advertising address type when toggling connectable · a4858cb9
      Johan Hedberg 提交于
      When the connectable setting is toggled using mgmt_set_connectable the
      HCI_CONNECTABLE flag will only be set once the related HCI commands
      succeed. When determining what kind of advertising to do we need to
      therefore also check whether there is a pending Set Connectable command
      in addition to the current flag value.
      
      The enable_advertising function was already taking care of this for the
      advertising type with the help of the get_adv_type function, but was
      failing to do the same for the address type selection. This patch
      converts the get_adv_type function to be more generic in that it returns
      the expected connectable state and updates the enable_advertising
      function to use the return value both for the advertising type as well
      as the advertising address type.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a4858cb9
  8. 25 2月, 2014 6 次提交
  9. 24 2月, 2014 8 次提交
  10. 23 2月, 2014 2 次提交
  11. 22 2月, 2014 1 次提交
  12. 21 2月, 2014 1 次提交
  13. 20 2月, 2014 3 次提交