1. 17 9月, 2015 1 次提交
  2. 29 8月, 2015 2 次提交
    • K
      Bluetooth: Fix SCO link type handling on connection complete · 618353b1
      Kuba Pawlak 提交于
      Synchronous connections are initially created with type eSCO.
      Link manager may reject proposed link parameters, which triggers
      connection setup retry with a different set. Link type embedded
      in responses should be disregarded until Synchronous Connect Complete
      returns Success (0x00). Current code updates link type every time
      which creates an issue when link type changes to SCO and back to eSCO
      on further attepts.
      
      Issue happens with BlackBerry 9100 and 9700 with Intel WilkinsPeak
      on third connection setup attept
      
      2015-05-18 01:27:57.332242 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
          handle 256 voice setting 0x0060 ptype 0x0380
      2015-05-18 01:27:57.333604 > HCI Event: Command Status (0x0f) plen 4
          Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
      2015-05-18 01:27:57.334614 > HCI Event: Synchronous Connect Complete (0x2c) plen 17
          status 0x1a handle 0 bdaddr 30:7C:30:B3:A8:86 type SCO
          Error: Unsupported Remote Feature / Unsupported LMP Feature
      2015-05-18 01:27:57.334895 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
          handle 256 voice setting 0x0060 ptype 0x0380
      2015-05-18 01:27:57.335601 > HCI Event: Command Status (0x0f) plen 4
          Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
      2015-05-18 01:27:57.336610 > HCI Event: Synchronous Connect Complete (0x2c) plen 17
          status 0x1a handle 0 bdaddr 30:7C:30:B3:A8:86 type SCO
          Error: Unsupported Remote Feature / Unsupported LMP Feature
      2015-05-18 01:27:57.336685 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
          handle 256 voice setting 0x0060 ptype 0x03c8
      2015-05-18 01:27:57.337603 > HCI Event: Command Status (0x0f) plen 4
          Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
      2015-05-18 01:27:57.342608 > HCI Event: Max Slots Change (0x1b) plen 3
          handle 256 slots 1
      2015-05-18 01:27:57.377631 > HCI Event: Synchronous Connect Complete (0x2c) plen 17
          status 0x00 handle 257 bdaddr 30:7C:30:B3:A8:86 type eSCO
          Air mode: CVSD
      Signed-off-by: NKuba Pawlak <kubax.t.pawlak@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      618353b1
    • N
      Bluetooth: Make the function sco_conn_del have a return type of void · df945360
      Nicholas Krause 提交于
      This makes the function sco_conn_del have a return type of void now
      due to this function always running successfully and thus never
      needing to signal its caller when a non recoverable internal failure
      occurs by returning a error code to its respective caller.
      Signed-off-by: NNicholas Krause <xerofoify@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      df945360
  3. 12 8月, 2015 2 次提交
  4. 11 8月, 2015 6 次提交
    • 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: timeout handling in new connect procedure · cc2b6911
      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 makes sure that when new procedure is in use, and we're stuck
      in scan phase because no advertisement was received and timeout happened,
      or app decided to close socket, scan whitelist gets properly cleaned up.
      Signed-off-by: NJakub Pawlowski <jpawlowski@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      cc2b6911
    • 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_connect_le_scan · f75113a2
      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 adds hci_connect_le_scan with dependencies, new method that
      will be used to connect to remote LE devices. Instead of just sending
      connect request, it adds a device to whitelist. Later patches will make
      use of this whitelist to send conenct request when advertisement is
      received, and properly handle timeouts.
      Signed-off-by: NJakub Pawlowski <jpawlowski@google.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f75113a2
    • 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
    • D
      Bluetooth: Fix breakage in amp_write_rem_assoc_frag() · 0208bc88
      Dan Carpenter 提交于
      We should be passing the pointer itself instead of the address of the
      pointer.
      
      This was a copy and paste bug when we replaced the calls to
      hci_send_cmd().  Originally, the arguments were "len, cp" but we
      overwrote them with "sizeof(cp), &cp" by mistake.
      
      Fixes: b3d39140 ('Bluetooth: Move amp assoc read/write completed callback to amp.c')
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0208bc88
  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. 30 7月, 2015 7 次提交
  7. 23 7月, 2015 7 次提交
  8. 05 7月, 2015 1 次提交
    • L
      bluetooth: fix list handling · 9b284cbd
      Linus Torvalds 提交于
      Commit 835a6a2f ("Bluetooth: Stop sabotaging list poisoning")
      thought that the code was sabotaging the list poisoning when NULL'ing
      out the list pointers and removed it.
      
      But what was going on was that the bluetooth code was using NULL
      pointers for the list as a way to mark it empty, and that commit just
      broke it (and replaced the test with NULL with a "list_empty()" test on
      a uninitialized list instead, breaking things even further).
      
      So fix it all up to use the regular and real list_empty() handling
      (which does not use NULL, but a pointer to itself), also making sure to
      initialize the list properly (the previous NULL case was initialized
      implicitly by the session being allocated with kzalloc())
      
      This is a combination of patches by Marcel Holtmann and Tedd Ho-Jeong
      An.
      
      [ I would normally expect to get this through the bt tree, but I'm going
        to release -rc1, so I'm just committing this directly   - Linus ]
      Reported-and-tested-by: NJörg Otte <jrg.otte@gmail.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Original-by: NTedd Ho-Jeong An <tedd.an@intel.com>
      Original-by: Marcel Holtmann <marcel@holtmann.org>:
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9b284cbd
  9. 01 7月, 2015 1 次提交
    • T
      Bluetooth: Reinitialize the list after deletion for session user list · ab944c83
      Tedd Ho-Jeong An 提交于
      If the user->list is deleted with list_del(), it doesn't initialize the
      entry which can cause the issue with list_empty(). According to the
      comment from the list.h, list_empty() returns false even if the list is
      empty and put the entry in an undefined state.
      
      /**
       * list_del - deletes entry from list.
       * @entry: the element to delete from the list.
       * Note: list_empty() on entry does not return true after this, the entry is
       * in an undefined state.
       */
      
      Because of this behavior, list_empty() returns false even if list is empty
      when the device is reconnected.
      
      So, user->list needs to be re-initialized after list_del(). list.h already
      have a macro list_del_init() which deletes the entry and initailze it again.
      Signed-off-by: NTedd Ho-Jeong An <tedd.an@intel.com>
      Tested-by: NJörg Otte <jrg.otte@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      ab944c83
  10. 27 6月, 2015 1 次提交
  11. 19 6月, 2015 11 次提交