1. 09 5月, 2012 6 次提交
  2. 29 3月, 2012 1 次提交
  3. 03 1月, 2012 1 次提交
  4. 23 12月, 2011 1 次提交
  5. 20 12月, 2011 1 次提交
  6. 19 12月, 2011 1 次提交
  7. 19 10月, 2011 1 次提交
  8. 12 8月, 2011 1 次提交
  9. 01 7月, 2011 1 次提交
  10. 11 6月, 2011 1 次提交
  11. 10 6月, 2011 1 次提交
  12. 12 5月, 2011 1 次提交
  13. 19 4月, 2011 1 次提交
  14. 28 2月, 2011 1 次提交
  15. 15 2月, 2011 1 次提交
    • G
      Bluetooth: Merge L2CAP and SCO modules into bluetooth.ko · 64274518
      Gustavo F. Padovan 提交于
      Actually doesn't make sense have these modules built separately.
      The L2CAP layer is needed by almost all Bluetooth protocols and profiles.
      There isn't any real use case without having L2CAP loaded.
      SCO is only essential for Audio transfers, but it is so small that we can
      have it loaded always in bluetooth.ko without problems.
      If you really doesn't want it you can disable SCO in the kernel config.
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      64274518
  16. 14 2月, 2011 1 次提交
  17. 02 12月, 2010 1 次提交
  18. 23 11月, 2010 1 次提交
  19. 18 5月, 2010 1 次提交
  20. 10 5月, 2010 2 次提交
  21. 21 4月, 2010 1 次提交
  22. 02 4月, 2010 1 次提交
  23. 21 3月, 2010 2 次提交
  24. 08 3月, 2010 1 次提交
  25. 06 11月, 2009 1 次提交
  26. 07 10月, 2009 1 次提交
  27. 01 10月, 2009 1 次提交
  28. 23 8月, 2009 1 次提交
    • M
      Bluetooth: Add proper shutdown support to SCO sockets · fd0b3ff7
      Marcel Holtmann 提交于
      The SCO sockets for Bluetooth audio setup and streaming are missing the
      shutdown implementation. This hasn't been a problem so far, but with a
      more deeper integration with PulseAudio it is important to shutdown SCO
      sockets properly.
      
      Also the Headset profile 1.2 has more detailed qualification tests that
      require that SCO and RFCOMM channels are terminated in the right order. A
      proper shutdown function is necessary for this.
      
      Based on a report by Johan Hedberg <johan.hedberg@nokia.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Tested-by: NJohan Hedberg <johan.hedberg@nokia.com>
      fd0b3ff7
  29. 27 2月, 2009 4 次提交
    • M
      Bluetooth: Ask upper layers for HCI disconnect reason · 2950f21a
      Marcel Holtmann 提交于
      Some of the qualification tests demand that in case of failures in L2CAP
      the HCI disconnect should indicate a reason why L2CAP fails. This is a
      bluntly layer violation since multiple L2CAP connections could be using
      the same ACL and thus forcing a disconnect reason is not a good idea.
      
      To comply with the Bluetooth test specification, the disconnect reason
      is now stored in the L2CAP connection structure and every time a new
      L2CAP channel is added it will set back to its default. So only in the
      case where the L2CAP channel with the disconnect reason is really the
      last one, it will propagated to the HCI layer.
      
      The HCI layer has been extended with a disconnect indication that allows
      it to ask upper layers for a disconnect reason. The upper layer must not
      support this callback and in that case it will nicely default to the
      existing behavior. If an upper layer like L2CAP can provide a disconnect
      reason that one will be used to disconnect the ACL or SCO link.
      
      No modification to the ACL disconnect timeout have been made. So in case
      of Linux to Linux connection the initiator will disconnect the ACL link
      before the acceptor side can signal the specific disconnect reason. That
      is perfectly fine since Linux doesn't make use of this value anyway. The
      L2CAP layer has a perfect valid error code for rejecting connection due
      to a security violation. It is unclear why the Bluetooth specification
      insists on having specific HCI disconnect reason.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2950f21a
    • M
      Bluetooth: Add enhanced security model for Simple Pairing · 8c1b2355
      Marcel Holtmann 提交于
      The current security model is based around the flags AUTH, ENCRYPT and
      SECURE. Starting with support for the Bluetooth 2.1 specification this is
      no longer sufficient. The different security levels are now defined as
      SDP, LOW, MEDIUM and SECURE.
      
      Previously it was possible to set each security independently, but this
      actually doesn't make a lot of sense. For Bluetooth the encryption depends
      on a previous successful authentication. Also you can only update your
      existing link key if you successfully created at least one before. And of
      course the update of link keys without having proper encryption in place
      is a security issue.
      
      The new security levels from the Bluetooth 2.1 specification are now
      used internally. All old settings are mapped to the new values and this
      way it ensures that old applications still work. The only limitation
      is that it is no longer possible to set authentication without also
      enabling encryption. No application should have done this anyway since
      this is actually a security issue. Without encryption the integrity of
      the authentication can't be guaranteed.
      
      As default for a new L2CAP or RFCOMM connection, the LOW security level
      is used. The only exception here are the service discovery sessions on
      PSM 1 where SDP level is used. To have similar security strength as with
      a Bluetooth 2.0 and before combination key, the MEDIUM level should be
      used. This is according to the Bluetooth specification. The MEDIUM level
      will not require any kind of man-in-the-middle (MITM) protection. Only
      the HIGH security level will require this.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8c1b2355
    • M
      Bluetooth: Reject incoming SCO connections without listeners · 71aeeaa1
      Marcel Holtmann 提交于
      All SCO and eSCO connection are auto-accepted no matter if there is a
      corresponding listening socket for them. This patch changes this and
      connection requests for SCO and eSCO without any socket are rejected.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      71aeeaa1
    • M
      Bluetooth: Preparation for usage of SOL_BLUETOOTH · d58daf42
      Marcel Holtmann 提交于
      The socket option levels SOL_L2CAP, SOL_RFOMM and SOL_SCO are currently
      in use by various Bluetooth applications. Going forward the common
      option level SOL_BLUETOOTH should be used. This patch prepares the clean
      split of the old and new option levels while keeping everything backward
      compatibility.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      d58daf42
  30. 30 11月, 2008 1 次提交