1. 07 Nov, 2011 1 commit
    • Arek Lichwa's avatar
      Bluetooth: Revert: Fix L2CAP connection establishment · 4dff523a
      Arek Lichwa authored
      This reverts commit 33060542
      
      .
      The commit introduces regression when two 2.1 devices attempt
      establish rfcomm channel. Such connection is refused since there's
      a security block issue on l2cap. It means the link is unencrypted.
      
      2011-09-16 18:08:46.567616 < ACL data: handle 1 flags 0x00 dlen 24
          0000: 14 00 40 00 06 00 02 00  0f 35 03 19 12 00 ff ff
      ..@......5....˙˙
          0010: 35 05 0a 00 00 ff ff 00                           5....˙˙.
      2011-09-16 18:08:46.572377 > HCI Event: Number of Completed Packets
      (0x13) plen 5
          handle 1 packets 1
      2011-09-16 18:08:46.577931 > ACL data: handle 1 flags 0x02 dlen 88
          L2CAP(d): cid 0x0040 len 84 [psm 0]
            0000: 07 00 02 00 4f 00 4c 35  4a 35 48 09 00 00 0a 00
      ....O.L5J5H.....
            0010: 01 00 00 09 00 01 35 03  19 12 00 09 00 05 35 03
      ......5.......5.
            0020: 19 10 02 09 00 09 35 08  35 06 19 12 00 09 01 02
      ......5.5.......
            0030: 09 02 00 09 01 02 09 02  01 09 00 0a 09 02 02 09
      ................
            0040: 00 00 09 02 03 09 00 00  09 02 04 28 01 09 02 05
      ...........(....
            0050: 09 00 02 00                                       ....
      2011-09-16 18:08:46.626057 < HCI Command: Authentication Requested
      (0x01|0x0011) plen 2
          handle 1
      2011-09-16 18:08:46.627614 > HCI Event: Command Status (0x0f) plen 4
          Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
      2011-09-16 18:08:46.627675 > HCI Event: Link Key Request (0x17) plen 6
          bdaddr 00:00:F2:6A:29:69
      2011-09-16 18:08:46.634999 < HCI Command: Link Key Request Reply
      (0x01|0x000b) plen 22
          bdaddr 00:00:F2:6A:29:69 key 58CD393179FC902E5E8F512A855EE532
      2011-09-16 18:08:46.683278 > HCI Event: Command Complete (0x0e) plen 10
          Link Key Request Reply (0x01|0x000b) ncmd 1
          status 0x00 bdaddr 00:00:F2:6A:29:69
      2011-09-16 18:08:46.764729 > HCI Event: Auth Complete (0x06) plen 3
          status 0x00 handle 1
      2011-09-16 18:08:46.764821 < ACL data: handle 1 flags 0x00 dlen 12
          0000: 08 00 01 00 02 05 04 00  03 00 41 00              ..........A.
      2011-09-16 18:08:46.764851 > HCI Event: Command Status (0x0f) plen 4
          Unknown (0x00|0x0000) status 0x00 ncmd 2
      2011-09-16 18:08:46.768117 > HCI Event: Number of Completed Packets
      (0x13) plen 5
          handle 1 packets 1
      2011-09-16 18:08:46.770894 > ACL data: handle 1 flags 0x02 dlen 16
          L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0041 result 3 status 0
            Connection refused - security block
      2011-09-16 18:08:49.000691 < ACL data: handle 1 flags 0x00 dlen 12
          0000: 08 00 01 00 06 06 04 00  40 00 40 00              ........@.@.
      2011-09-16 18:08:49.015675 > HCI Event: Number of Completed Packets
      (0x13) plen 5
          handle 1 packets 1
      2011-09-16 18:08:49.016927 > ACL data: handle 1 flags 0x02 dlen 12
          L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
      2011-09-16 18:08:51.009480 < HCI Command: Disconnect (0x01|0x0006) plen
      3
          handle 1 reason 0x13
          Reason: Remote User Terminated Connection
      2011-09-16 18:08:51.011525 > HCI Event: Command Status (0x0f) plen 4
          Disconnect (0x01|0x0006) status 0x00 ncmd 1
      2011-09-16 18:08:51.123494 > HCI Event: Disconn Complete (0x05) plen 4
          status 0x00 handle 1 reason 0x16
          Reason: Connection Terminated by Local Host
      Signed-off-by: default avatarArek Lichwa <arkadiusz.lichwa@tieto.com>
      Signed-off-by: default avatarGustavo F. Padovan <padovan@profusion.mobi>
      4dff523a
  2. 27 Sep, 2011 1 commit
    • Anderson Lizardo's avatar
      Bluetooth: use recommended LE connection parameters · 0e833915
      Anderson Lizardo authored
      
      
      The new connection parameters now match the recommended values for
      Proximity and Health Thermometer profiles. The previous values were
      ramdomly chosen, and are either too low or too high for most cases.
      
      New values:
      
      Scan Interval: 60 ms
      Scan Window: 30 ms
      Minimum Connection Interval: 50 ms
      Maximum Connection Interval: 70 ms
      Supervision Timeout: 420 ms
      
      See "Table 5.2: Recommended Scan Interval and Scan Window Values" and
      "Table 5.3: Recommended Connection Interval Values" for both profiles
      for details. Note that the "fast connection" parameters were chosen,
      because we do not support yet dynamically changing these parameters from
      initiator side.
      
      Additionally, the Proximity profile recommends (section "4.4 Alert on
      Link Loss"):
      
      "It is recommended that the Link Supervision Timeout (LSTO) is set to 6x
      the connection interval."
      
      Minimum_CE_Length and Maximum_CE_Length were also changed from 0x0001 to
      0x0000 because they are informational and optional, and old value was
      not reflecting reality.
      Signed-off-by: default avatarAnderson Lizardo <anderson.lizardo@openbossa.org>
      Signed-off-by: default avatarGustavo F. Padovan <padovan@profusion.mobi>
      0e833915
  3. 21 Sep, 2011 1 commit
  4. 30 Jun, 2011 1 commit
  5. 15 Jun, 2011 1 commit
  6. 13 Jun, 2011 3 commits
  7. 08 Jun, 2011 6 commits
  8. 11 May, 2011 1 commit
  9. 28 Apr, 2011 2 commits
  10. 27 Feb, 2011 1 commit
  11. 21 Feb, 2011 2 commits
  12. 16 Feb, 2011 4 commits
  13. 07 Feb, 2011 1 commit
  14. 19 Jan, 2011 3 commits
  15. 01 Dec, 2010 1 commit
  16. 27 Jul, 2010 1 commit
    • Marcel Holtmann's avatar
      Bluetooth: Defer SCO setup if mode change is pending · e73439d8
      Marcel Holtmann authored
      
      
      Certain headsets such as the Motorola H350 will reject SCO and eSCO
      connection requests while the ACL is transitioning from sniff mode
      to active mode. Add synchronization so that SCO and eSCO connection
      requests will wait until the ACL has fully transitioned to active mode.
      
      < HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2
          handle 12
      > HCI Event: Command Status (0x0f) plen 4
          Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
      < HCI Command:  Setup Synchronous Connection (0x01|0x0028) plen 17
          handle 12 voice setting 0x0040
      > HCI Event: Command Status (0x0f) plen 4
          Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
      > HCI Event: Number of Completed Packets (0x13) plen 5
          handle 12 packets 1
      > HCI Event: Mode Change (0x14) plen 6
          status 0x00 handle 12 mode 0x00 interval 0
          Mode: Active
      > HCI Event: Synchronous Connect Complete (0x2c) plen 17
          status 0x10 handle 14 bdaddr 00:1A:0E:50:28:A4 type SCO
          Error: Connection Accept Timeout Exceeded
      Signed-off-by: default avatarRon Shaffer <rshaffer@codeaurora.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      e73439d8
  17. 21 Jul, 2010 1 commit
  18. 08 Jul, 2010 1 commit
  19. 03 Feb, 2010 1 commit
    • Nick Pelly's avatar
      Bluetooth: Enter active mode before establishing a SCO link. · c390216b
      Nick Pelly authored
      
      
      When in sniff mode with a long interval time (1.28s) it can take 4+ seconds
      to establish a SCO link. Fix by requesting active mode before requesting
      SCO connection. This improves SCO setup time to ~500ms.
      
      Bluetooth headsets that use a long interval time, and exhibit the long
      SCO connection time include Motorola H790, HX1 and H17. They have a
      CSR 2.1 chipset.
      
      Verified this behavior and fix with host Bluetooth chipsets: BCM4329 and
      TI1271.
      
      2009-10-13 14:17:46.183722 > HCI Event: Mode Change (0x14) plen 6
          status 0x00 handle 1 mode 0x02 interval 2048
          Mode: Sniff
      2009-10-13 14:17:53.436285 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
          handle 1 voice setting 0x0060
      2009-10-13 14:17:53.445593 > HCI Event: Command Status (0x0f) plen 4
          Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
      2009-10-13 14:17:57.788855 > HCI Event: Synchronous Connect Complete 0x2c) plen 17
          status 0x00 handle 257 bdaddr 00:1A:0E:F1:A4:7F type eSCO
          Air mode: CVSD
      Signed-off-by: default avatarNick Pelly <npelly@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c390216b
  20. 15 Nov, 2009 1 commit
  21. 22 Aug, 2009 1 commit
    • Marcel Holtmann's avatar
      Bluetooth: Add extra device reference counting for connections · 9eba32b8
      Marcel Holtmann authored
      
      
      The device model itself has no real usable reference counting at the
      moment and this causes problems if parents are deleted before their
      children. The device model itself handles the memory details of this
      correctly, but the uevent order is not consistent. This causes various
      problems for systems like HAL or even X.
      
      So until device_put() does a proper cleanup, the device for Bluetooth
      connection will be protected with an extra reference counting to ensure
      the correct order of uevents when connections are terminated.
      
      This is not an automatic feature. Higher Bluetooth layers like HIDP or
      BNEP should grab this new reference to ensure that their uevents are
      send before the ones from the parent device.
      
      Based on a report by Brian Rogers <brian@xyzw.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      9eba32b8
  22. 09 May, 2009 2 commits
    • Marcel Holtmann's avatar
      Bluetooth: Don't use hci_acl_connect_cancel() for incoming connections · 1b0336bb
      Marcel Holtmann authored
      
      
      The connection setup phase takes around 2 seconds or longer and in
      that time it is possible that the need for an ACL connection is no
      longer present. If that happens then, the connection attempt will
      be canceled.
      
      This only applies to outgoing connections, but currently it can also
      be triggered by incoming connection. Don't call hci_acl_connect_cancel()
      on incoming connection since these have to be either accepted or rejected
      in this state. Once they are successfully connected they need to be
      fully disconnected anyway.
      
      Also remove the wrong hci_acl_disconn() call for SCO and eSCO links
      since at this stage they can't be disconnected either, because the
      connection handle is still unknown.
      
      Based on a report by Johan Hedberg <johan.hedberg@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Tested-by: default avatarJohan Hedberg <johan.hedberg@nokia.com>
      1b0336bb
    • Marcel Holtmann's avatar
      Bluetooth: Fix wrong module refcount when connection setup fails · 384943ec
      Marcel Holtmann authored
      
      
      The module refcount is increased by hci_dev_hold() call in hci_conn_add()
      and decreased by hci_dev_put() call in del_conn(). In case the connection
      setup fails, hci_dev_put() is never called.
      
      Procedure to reproduce the issue:
      
        # hciconfig hci0 up
        # lsmod | grep btusb                   -> "used by" refcount = 1
      
        # hcitool cc <non-exisiting bdaddr>    -> will get timeout
      
        # lsmod | grep btusb                   -> "used by" refcount = 2
        # hciconfig hci0 down
        # lsmod | grep btusb                   -> "used by" refcount = 1
        # rmmod btusb                          -> ERROR: Module btusb is in use
      
      The hci_dev_put() call got moved into del_conn() with the 2.6.25 kernel
      to fix an issue with hci_dev going away before hci_conn. However that
      change was wrong and introduced this problem.
      
      When calling hci_conn_del() it has to call hci_dev_put() after freeing
      the connection details. This handling should be fully symmetric. The
      execution of del_conn() is done in a work queue and needs it own calls
      to hci_dev_hold() and hci_dev_put() to ensure that the hci_dev stays
      until the connection cleanup has been finished.
      
      Based on a report by Bing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Tested-by: default avatarBing Zhao <bzhao@marvell.com>
      384943ec
  23. 04 May, 2009 1 commit
    • Marcel Holtmann's avatar
      Bluetooth: Fix issue with sysfs handling for connections · a67e899c
      Marcel Holtmann authored
      
      
      Due to a semantic changes in flush_workqueue() the current approach of
      synchronizing the sysfs handling for connections doesn't work anymore. The
      whole approach is actually fully broken and based on assumptions that are
      no longer valid.
      
      With the introduction of Simple Pairing support, the creation of low-level
      ACL links got changed. This change invalidates the reason why in the past
      two independent work queues have been used for adding/removing sysfs
      devices. The adding of the actual sysfs device is now postponed until the
      host controller successfully assigns an unique handle to that link. So
      the real synchronization happens inside the controller and not the host.
      
      The only left-over problem is that some internals of the sysfs device
      handling are not initialized ahead of time. This leaves potential access
      to invalid data and can cause various NULL pointer dereferences. To fix
      this a new function makes sure that all sysfs details are initialized
      when an connection attempt is made. The actual sysfs device is only
      registered when the connection has been successfully established. To
      avoid a race condition with the registration, the check if a device is
      registered has been moved into the removal work.
      
      As an extra protection two flush_work() calls are left in place to
      make sure a previous add/del work has been completed first.
      
      Based on a report by Marc Pignat <marc.pignat@hevs.ch>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Tested-by: default avatarJustin P. Mattock <justinmattock@gmail.com>
      Tested-by: default avatarRoger Quadros <ext-roger.quadros@nokia.com>
      Tested-by: default avatarMarc Pignat <marc.pignat@hevs.ch>
      a67e899c
  24. 28 Apr, 2009 2 commits
    • Marcel Holtmann's avatar
      Bluetooth: Fix connection establishment with low security requirement · 3fdca1e1
      Marcel Holtmann authored
      
      
      The Bluetooth 2.1 specification introduced four different security modes
      that can be mapped using Legacy Pairing and Simple Pairing. With the
      usage of Simple Pairing it is required that all connections (except
      the ones for SDP) are encrypted. So even the low security requirement
      mandates an encrypted connection when using Simple Pairing. When using
      Legacy Pairing (for Bluetooth 2.0 devices and older) this is not required
      since it causes interoperability issues.
      
      To support this properly the low security requirement translates into
      different host controller transactions depending if Simple Pairing is
      supported or not. However in case of Simple Pairing the command to
      switch on encryption after a successful authentication is not triggered
      for the low security mode. This patch fixes this and actually makes
      the logic to differentiate between Simple Pairing and Legacy Pairing
      a lot simpler.
      
      Based on a report by Ville Tervo <ville.tervo@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      3fdca1e1
    • Marcel Holtmann's avatar
      Bluetooth: Add different pairing timeout for Legacy Pairing · 052b30b0
      Marcel Holtmann authored
      
      
      The Bluetooth stack uses a reference counting for all established ACL
      links and if no user (L2CAP connection) is present, the link will be
      terminated to save power. The problem part is the dedicated pairing
      when using Legacy Pairing (Bluetooth 2.0 and before). At that point
      no user is present and pairing attempts will be disconnected within
      10 seconds or less. In previous kernel version this was not a problem
      since the disconnect timeout wasn't triggered on incoming connections
      for the first time. However this caused issues with broken host stacks
      that kept the connections around after dedicated pairing. When the
      support for Simple Pairing got added, the link establishment procedure
      needed to be changed and now causes issues when using Legacy Pairing
      
      When using Simple Pairing it is possible to do a proper reference
      counting of ACL link users. With Legacy Pairing this is not possible
      since the specification is unclear in some areas and too many broken
      Bluetooth devices have already been deployed. So instead of trying to
      deal with all the broken devices, a special pairing timeout will be
      introduced that increases the timeout to 60 seconds when pairing is
      triggered.
      
      If a broken devices now puts the stack into an unforeseen state, the
      worst that happens is the disconnect timeout triggers after 120 seconds
      instead of 4 seconds. This allows successful pairings with legacy and
      broken devices now.
      
      Based on a report by Johan Hedberg <johan.hedberg@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      052b30b0