1. 14 Jul, 2008 2 commits
    • 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 23 commits