1. 07 7月, 2011 4 次提交
  2. 14 6月, 2011 1 次提交
  3. 09 6月, 2011 2 次提交
  4. 29 4月, 2011 1 次提交
  5. 25 4月, 2011 1 次提交
  6. 01 4月, 2011 5 次提交
  7. 25 3月, 2011 1 次提交
  8. 22 2月, 2011 1 次提交
  9. 17 2月, 2011 4 次提交
  10. 08 2月, 2011 11 次提交
  11. 08 12月, 2010 1 次提交
  12. 02 12月, 2010 2 次提交
  13. 12 10月, 2010 1 次提交
  14. 22 7月, 2010 2 次提交
  15. 27 2月, 2010 2 次提交
  16. 29 4月, 2009 1 次提交
    • M
      Bluetooth: Add different pairing timeout for Legacy Pairing · 052b30b0
      Marcel Holtmann 提交于
      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: NMarcel Holtmann <marcel@holtmann.org>
      052b30b0