1. 03 1月, 2012 1 次提交
  2. 23 12月, 2011 1 次提交
  3. 20 12月, 2011 1 次提交
  4. 19 12月, 2011 1 次提交
  5. 19 10月, 2011 1 次提交
  6. 12 8月, 2011 1 次提交
  7. 01 7月, 2011 1 次提交
  8. 11 6月, 2011 1 次提交
  9. 10 6月, 2011 1 次提交
  10. 12 5月, 2011 1 次提交
  11. 19 4月, 2011 1 次提交
  12. 28 2月, 2011 1 次提交
  13. 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
  14. 14 2月, 2011 1 次提交
  15. 02 12月, 2010 1 次提交
  16. 23 11月, 2010 1 次提交
  17. 18 5月, 2010 1 次提交
  18. 10 5月, 2010 2 次提交
  19. 21 4月, 2010 1 次提交
  20. 02 4月, 2010 1 次提交
  21. 21 3月, 2010 2 次提交
  22. 08 3月, 2010 1 次提交
  23. 06 11月, 2009 1 次提交
  24. 07 10月, 2009 1 次提交
  25. 01 10月, 2009 1 次提交
  26. 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
  27. 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
  28. 30 11月, 2008 1 次提交
  29. 09 9月, 2008 1 次提交
    • M
      [Bluetooth] Enforce correct authentication requirements · 09ab6f4c
      Marcel Holtmann 提交于
      With the introduction of Security Mode 4 and Simple Pairing from the
      Bluetooth 2.1 specification it became mandatory that the initiator
      requires authentication and encryption before any L2CAP channel can
      be established. The only exception here is PSM 1 for the service
      discovery protocol (SDP). It is meant to be used without any encryption
      since it contains only public information. This is how Bluetooth 2.0
      and before handle connections on PSM 1.
      
      For Bluetooth 2.1 devices the pairing procedure differentiates between
      no bonding, general bonding and dedicated bonding. The L2CAP layer
      wrongly uses always general bonding when creating new connections, but it
      should not do this for SDP connections. In this case the authentication
      requirement should be no bonding and the just-works model should be used,
      but in case of non-SDP connection it is required to use general bonding.
      
      If the new connection requires man-in-the-middle (MITM) protection, it
      also first wrongly creates an unauthenticated link key and then later on
      requests an upgrade to an authenticated link key to provide full MITM
      protection. With Simple Pairing the link key generation is an expensive
      operation (compared to Bluetooth 2.0 and before) and doing this twice
      during a connection setup causes a noticeable delay when establishing
      a new connection. This should be avoided to not regress from the expected
      Bluetooth 2.0 connection times. The authentication requirements are known
      up-front and so enforce them.
      
      To fulfill these requirements the hci_connect() function has been extended
      with an authentication requirement parameter that will be stored inside
      the connection information and can be retrieved by userspace at any
      time. This allows the correct IO capabilities exchange and results in
      the expected behavior.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      09ab6f4c
  30. 18 8月, 2008 1 次提交
    • M
      [Bluetooth] Consolidate maintainers information · 63fbd24e
      Marcel Holtmann 提交于
      The Bluetooth entries for the MAINTAINERS file are a little bit too
      much. Consolidate them into two entries. One for Bluetooth drivers and
      another one for the Bluetooth subsystem.
      
      Also the MODULE_AUTHOR should indicate the current maintainer of the
      module and actually not the original author. Fix all Bluetooth modules
      to provide current maintainer information.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      63fbd24e
  31. 15 7月, 2008 2 次提交
  32. 29 3月, 2008 1 次提交
  33. 26 3月, 2008 1 次提交
  34. 29 1月, 2008 1 次提交