1. 14 Jul, 2008 5 commits
    • Marcel Holtmann's avatar
      [Bluetooth] Support the case when headset falls back to SCO link · 9dc0a3af
      Marcel Holtmann authored
      When trying to establish an eSCO link between two devices then it can
      happen that the remote device falls back to a SCO link. Currently this
      case is not handled correctly and the message dispatching will break
      since it is looking for eSCO packets. So in case the configured link
      falls back to SCO overwrite the link type with the correct value.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      9dc0a3af
    • Marcel Holtmann's avatar
      [Bluetooth] Update authentication status after successful encryption · ae293196
      Marcel Holtmann authored
      The authentication status is not communicated to both parties. This is
      actually a flaw in the Bluetooth specification. Only the requesting side
      really knows if the authentication was successful or not. This piece of
      information is however needed on the other side to know if it has to
      trigger the authentication procedure or not. Worst case is that both
      sides will request authentication at different times, but this should
      be avoided since it costs extra time when setting up a new connection.
      
      For Bluetooth encryption it is required to authenticate the link first
      and the encryption status is communicated to both sides. So when a link
      is switched to encryption it is possible to update the authentication
      status since it implies an authenticated link.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      ae293196
    • Marcel Holtmann's avatar
      [Bluetooth] Disconnect when encryption gets disabled · 9719f8af
      Marcel Holtmann authored
      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: default avatarMarcel Holtmann <marcel@holtmann.org>
      9719f8af
    • Marcel Holtmann's avatar
      [Bluetooth] Enforce security for outgoing RFCOMM connections · 77db1980
      Marcel Holtmann authored
      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: default avatarMarcel Holtmann <marcel@holtmann.org>
      77db1980
    • Marcel Holtmann's avatar
      [Bluetooth] Change retrieval of L2CAP features mask · 79d554a6
      Marcel Holtmann authored
      Getting the remote L2CAP features mask is really important, but doing
      this as less intrusive as possible is tricky. To play nice with older
      systems and Bluetooth qualification testing, the features mask is now
      only retrieved in two specific cases and only once per lifetime of an
      ACL link.
      
      When trying to establish a L2CAP connection and the remote features mask
      is unknown, the L2CAP information request is sent when the ACL link goes
      into connected state. This applies only to outgoing connections and also
      only for the connection oriented channels.
      
      The second case is when a connection request has been received. In this
      case a connection response with the result pending and the information
      request will be send. After receiving an information response or if the
      timeout gets triggered, the normal connection setup process with security
      setup will be initiated.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      79d554a6
  2. 05 Jul, 2008 15 commits
  3. 04 Jul, 2008 20 commits