1. 15 7月, 2008 2 次提交
    • M
      [Bluetooth] Disconnect when encryption gets disabled · 9719f8af
      Marcel Holtmann 提交于
      The Bluetooth specification allows to enable or disable the encryption
      of an ACL link at any time by either the peer or the remote device. If
      a L2CAP or RFCOMM connection requested an encrypted link, they will now
      disconnect that link if the encryption gets disabled. Higher protocols
      that don't care about encryption (like SDP) are not affected.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      9719f8af
    • M
      [Bluetooth] Enforce security for outgoing RFCOMM connections · 77db1980
      Marcel Holtmann 提交于
      Recent tests with various Bluetooth headsets have shown that some of
      them don't enforce authentication and encryption when connecting. All
      of them leave it up to the host stack to enforce it. Non of them should
      allow unencrypted connections, but that is how it is. So in case the
      link mode settings require authentication and/or encryption it will now
      also be enforced on outgoing RFCOMM connections. Previously this was
      only done for incoming connections.
      
      This support has a small drawback from a protocol level point of view
      since the host stack can't really tell with 100% certainty if a remote
      side is already authenticated or not. So if both sides are configured
      to enforce authentication it will be requested twice. Most Bluetooth
      chips are caching this information and thus no extra authentication
      procedure has to be triggered over-the-air, but it can happen.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      77db1980
  2. 06 3月, 2008 1 次提交
  3. 29 1月, 2008 1 次提交
  4. 22 10月, 2007 5 次提交
  5. 31 7月, 2007 1 次提交
  6. 11 7月, 2007 3 次提交
  7. 24 5月, 2007 1 次提交
  8. 26 4月, 2007 1 次提交
  9. 14 12月, 2006 1 次提交
  10. 03 12月, 2006 1 次提交
  11. 16 10月, 2006 1 次提交
    • M
      [Bluetooth] Support concurrent connect requests · 4c67bc74
      Marcel Holtmann 提交于
      Most Bluetooth chips don't support concurrent connect requests, because
      this would involve a multiple baseband page with only one radio. In the
      case an upper layer like L2CAP requests a concurrent connect these chips
      return the error "Command Disallowed" for the second request. If this
      happens it the responsibility of the Bluetooth core to queue the request
      and try again after the previous connect attempt has been completed.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      4c67bc74
  12. 29 9月, 2006 5 次提交
  13. 04 7月, 2006 4 次提交
  14. 13 2月, 2006 1 次提交
  15. 09 11月, 2005 2 次提交
  16. 29 10月, 2005 2 次提交
  17. 09 10月, 2005 1 次提交
  18. 13 9月, 2005 1 次提交
  19. 30 8月, 2005 6 次提交