1. 14 8月, 2014 1 次提交
  2. 31 7月, 2014 2 次提交
  3. 28 7月, 2014 1 次提交
  4. 24 7月, 2014 2 次提交
    • M
      Bluetooth: Fix issue with ADV_IND reports and auto-connection handling · 4b9e7e75
      Marcel Holtmann 提交于
      When adding remote devices to the kernel using the Add Device management
      command, these devices are explicitly allowed to connect. This kind of
      incoming connections are possible even when the controller itself is
      not connectable.
      
      For BR/EDR this distinction is pretty simple since there is only one
      type of incoming connections. With LE this is not that simple anymore
      since there are ADV_IND and ADV_DIRECT_IND advertising events.
      
      The ADV_DIRECT_IND advertising events are send for incoming (slave
      initiated) connections only. And this is the only thing the kernel
      should allow when adding devices using action 0x01. This meaning
      of incoming connections is coming from BR/EDR and needs to be
      mapped to LE the same way.
      
      Supporting the auto-connection of devices using ADV_IND advertising
      events is an important feature as well. However it does not map to
      incoming connections. So introduce a new action 0x02 that allows
      the kernel to connect to devices using ADV_DIRECT_IND and in addition
      ADV_IND advertising reports.
      
      This difference is represented by the new HCI_AUTO_CONN_DIRECT value
      for only connecting to ADV_DIRECT_IND. For connection to ADV_IND and
      ADV_DIRECT_IND the old value HCI_AUTO_CONN_ALWAYS is used.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      4b9e7e75
    • M
      Bluetooth: Ignore ADV_DIRECT_IND attempts from unknown devices · cd4d5671
      Marcel Holtmann 提交于
      Unconditionally connecting to devices sending ADV_DIRECT_IND when
      the controller is in CONNECTABLE mode is a feature that is not
      fully working. The background scanning trigger for this has been
      removed, but the statement allowing it to happen in case some
      other part triggers is still present. So remove that code part
      as well to avoid unwanted connections.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      cd4d5671
  5. 17 7月, 2014 5 次提交
  6. 16 7月, 2014 6 次提交
  7. 15 7月, 2014 2 次提交
  8. 11 7月, 2014 2 次提交
    • J
      Bluetooth: Fix tracking local SSP authentication requirement · 6c53823a
      Johan Hedberg 提交于
      When we need to make the decision whether to perform just-works or real
      user confirmation we need to know the exact local authentication
      requirement that was passed to the controller. So far conn->auth_type
      (the local requirement) wasn't in one case updated appropriately in fear
      of the user confirmation being rejected later.
      
      The real problem however was not really that conn->auth_type couldn't
      represent the true value but that we were checking the local MITM
      requirement in an incorrect way. It's perfectly fine to let auth_type
      follow what we tell the controller since we're still tracking the target
      security level with conn->pending_sec_level.
      
      This patch updates the check for local MITM requirement in the
      hci_user_confirm_request_evt function to use the locally requested
      security level and ensures that auth_type always represents what we tell
      the controller. All other code in hci_user_confirm_request_evt still
      uses the auth_type instead of pending_sec_level for determining whether
      to do just-works or not, since that's the only value that's in sync with
      what the remote device knows.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Tested-by: NSzymon Janc <szymon.janc@tieto.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org # 3.16
      6c53823a
    • M
      Bluetooth: Move HCI request internals to net/bluetooth/hci_core.c · 899de765
      Marcel Holtmann 提交于
      The internals of the HCI request framework should not be leaking to
      its users. Move them all into net/bluetooth/hci_core.c and provide
      a simple hci_req_pending helper function for the one user outside
      the framework.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      899de765
  9. 10 7月, 2014 3 次提交
  10. 09 7月, 2014 3 次提交
  11. 08 7月, 2014 5 次提交
  12. 07 7月, 2014 4 次提交
  13. 06 7月, 2014 2 次提交
  14. 05 7月, 2014 2 次提交