1. 22 10月, 2015 3 次提交
  2. 21 10月, 2015 2 次提交
    • J
      Bluetooth: Fix removing connection parameters when unpairing · a6ad2a6b
      Johan Hedberg 提交于
      The commit 89cbb063 introduced support for deferred connection
      parameter removal when unpairing by removing them only once an
      existing connection gets disconnected. However, it failed to address
      the scenario when we're *not* connected and do an unpair operation.
      
      What makes things worse is that most user space BlueZ versions will
      first issue a disconnect request and only then unpair, meaning the
      buggy code will be triggered every time. This effectively causes the
      kernel to resume scanning and reconnect to a device for which we've
      removed all keys and GATT database information.
      
      This patch fixes the issue by adding the missing call to the
      hci_conn_params_del() function to a branch which handles the case of
      no existing connection.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org # 3.19+
      a6ad2a6b
    • J
      Bluetooth: Don't use remote address type to decide IRK persistency · cad20c27
      Johan Hedberg 提交于
      There are LE devices on the market that start off by announcing their
      public address and then once paired switch to using private address.
      To be interoperable with such devices we should simply trust the fact
      that we're receiving an IRK from them to indicate that they may use
      private addresses in the future. Instead, simply tie the persistency
      to the bonding/no-bonding information the same way as for LTKs and
      CSRKs.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      cad20c27
  3. 16 10月, 2015 4 次提交
  4. 11 8月, 2015 3 次提交
    • J
      Bluetooth: Enable new connection establishment procedure. · fa142220
      Jakub Pawlowski 提交于
      Currently, when trying to connect to already paired device that just
      rotated its RPA MAC address, old address would be used and connection
      would fail. In order to fix that, kernel must scan and receive
      advertisement with fresh RPA before connecting.
      
      This patch enables new connection establishment procedure. Instead of just
      sending HCI_OP_LE_CREATE_CONN to controller, "connect" will add device to
      kernel whitelist and start scan. If advertisement is received, it'll be
      compared against whitelist and then trigger connection if it matches.
      That fixes mentioned reconnect issue for  already paired devices. It also
      make whole connection procedure more robust. We can try to connect to
      multiple devices at same time now, even though controller allow only one.
      Signed-off-by: NJakub Pawlowski <jpawlowski@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      fa142220
    • J
      Bluetooth: advertisement handling in new connect procedure · 28a667c9
      Jakub Pawlowski 提交于
      Currently, when trying to connect to already paired device that just
      rotated its RPA MAC address, old address would be used and connection
      would fail. In order to fix that, kernel must scan and receive
      advertisement with fresh RPA before connecting.
      
      This path makes sure that after advertisement is received from device that
      we try to connect to, it is properly handled in check_pending_le_conn and
      trigger connect attempt.
      
      It also modifies hci_le_connect to make sure that connect attempt will be
      properly continued.
      Signed-off-by: NJakub Pawlowski <jpawlowski@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      28a667c9
    • J
      Bluetooth: add hci_lookup_le_connect · e7d9ab73
      Jakub Pawlowski 提交于
      This patch adds hci_lookup_le_connect method, that will be used to check
      wether outgoing le connection attempt is in progress.
      Signed-off-by: NJakub Pawlowski <jpawlowski@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e7d9ab73
  5. 06 8月, 2015 1 次提交
    • J
      Bluetooth: fix MGMT_EV_NEW_LONG_TERM_KEY event · cb92205b
      Jakub Pawlowski 提交于
      This patch fixes how MGMT_EV_NEW_LONG_TERM_KEY event is build. Right now
      val vield is filled with only 1 byte, instead of whole value. This bug
      was introduced in
      commit 1fc62c52 ("Bluetooth: Fix exposing full value of shortened LTKs")
      
      Before that patch, if you paired with device using bluetoothd using simple
      pairing, and then restarted bluetoothd, you would be able to re-connect,
      but device would fail to establish encryption and would terminate
      connection. After this patch connecting after bluetoothd restart works
      fine.
      Signed-off-by: NJakub Pawlowski <jpawlowski@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      cb92205b
  6. 23 7月, 2015 1 次提交
  7. 19 6月, 2015 20 次提交
  8. 10 6月, 2015 1 次提交
  9. 26 5月, 2015 1 次提交
  10. 08 4月, 2015 1 次提交
  11. 04 4月, 2015 1 次提交
  12. 03 4月, 2015 1 次提交
  13. 02 4月, 2015 1 次提交