1. 27 Feb, 2009 15 commits
    • Dave Young's avatar
      Bluetooth: Remove CONFIG_DEBUG_LOCK_ALLOC ifdefs · dd2efd03
      Dave Young authored
      Due to lockdep changes, the CONFIG_DEBUG_LOCK_ALLOC ifdef is not needed
      now. So just remove it here.
      
      The following commit fixed the !lockdep build warnings:
      
      commit e8f6fbf6
      Author: Ingo Molnar <mingo@elte.hu>
      Date:   Wed Nov 12 01:38:36 2008 +0000
      
          lockdep: include/linux/lockdep.h - fix warning in net/bluetooth/af_bluetooth.c
      Signed-off-by: default avatarDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      dd2efd03
    • Marcel Holtmann's avatar
      Bluetooth: Update version numbers · 5f9018af
      Marcel Holtmann authored
      With the support for the enhanced security model and the support for
      deferring connection setup, it is a good idea to increase various
      version numbers.
      
      This is purely cosmetic and has no effect on the behavior, but can
      be really helpful when debugging problems in different kernel versions.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      5f9018af
    • Marcel Holtmann's avatar
      Bluetooth: Restrict application of socket options · 0588d94f
      Marcel Holtmann authored
      The new socket options should only be evaluated for SOL_BLUETOOTH level
      and not for every other level. Previously this causes some minor issues
      when detecting if a kernel with certain features is available.
      
      Also restrict BT_SECURITY to SOCK_SEQPACKET for L2CAP and SOCK_STREAM for
      the RFCOMM protocol.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      0588d94f
    • Marcel Holtmann's avatar
      Bluetooth: Disconnect L2CAP connections without encryption · f62e4323
      Marcel Holtmann authored
      For L2CAP connections with high security setting, the link will be
      immediately dropped when the encryption gets disabled. For L2CAP
      connections with medium security there will be grace period where
      the remote device has the chance to re-enable encryption. If it
      doesn't happen then the link will also be disconnected.
      
      The requirement for the grace period with medium security comes from
      Bluetooth 2.0 and earlier devices that require role switching.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f62e4323
    • Marcel Holtmann's avatar
      Bluetooth: Pause RFCOMM TX when encryption drops · 8c84b830
      Marcel Holtmann authored
      A role switch with devices following the Bluetooth pre-2.1 standards
      or without Encryption Pause and Resume support is not possible if
      encryption is enabled. Most newer headsets require the role switch,
      but also require that the connection is encrypted.
      
      For connections with a high security mode setting, the link will be
      immediately dropped. When the connection uses medium security mode
      setting, then a grace period is introduced where the TX is halted and
      the remote device gets a change to re-enable encryption after the
      role switch. If not re-enabled the link will be dropped.
      
      Based on initial work by Ville Tervo <ville.tervo@nokia.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      8c84b830
    • Marcel Holtmann's avatar
      Bluetooth: Replace RFCOMM link mode with security level · 9f2c8a03
      Marcel Holtmann authored
      Change the RFCOMM internals to use the new security levels and remove
      the link mode details.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      9f2c8a03
    • Marcel Holtmann's avatar
      Bluetooth: Replace L2CAP link mode with security level · 2af6b9d5
      Marcel Holtmann authored
      Change the L2CAP internals to use the new security levels and remove
      the link mode details.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      2af6b9d5
    • Marcel Holtmann's avatar
      Bluetooth: Add enhanced security model for Simple Pairing · 8c1b2355
      Marcel Holtmann authored
      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: default avatarMarcel Holtmann <marcel@holtmann.org>
      8c1b2355
    • Marcel Holtmann's avatar
      Bluetooth: Fix SCO state handling for incoming connections · c89b6e6b
      Marcel Holtmann authored
      When the remote device supports only SCO connections, on receipt of
      the HCI_EV_CONN_COMPLETE event packet, the connect state is changed to
      BT_CONNECTED, but the socket state is not updated. Hence, the connect()
      call times out even though the SCO connection has been successfully
      established.
      
      Based on a report by Jaikumar Ganesh <jaikumar@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c89b6e6b
    • Marcel Holtmann's avatar
      Bluetooth: Reject incoming SCO connections without listeners · 71aeeaa1
      Marcel Holtmann authored
      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: default avatarMarcel Holtmann <marcel@holtmann.org>
      71aeeaa1
    • Marcel Holtmann's avatar
      Bluetooth: Add support for deferring L2CAP connection setup · f66dc81f
      Marcel Holtmann authored
      In order to decide if listening L2CAP sockets should be accept()ed
      the BD_ADDR of the remote device needs to be known. This patch adds
      a socket option which defines a timeout for deferring the actual
      connection setup.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f66dc81f
    • Marcel Holtmann's avatar
      Bluetooth: Add support for deferring RFCOMM connection setup · bb23c0ab
      Marcel Holtmann authored
      In order to decide if listening RFCOMM sockets should be accept()ed
      the BD_ADDR of the remote device needs to be known. This patch adds
      a socket option which defines a timeout for deferring the actual
      connection setup.
      
      The connection setup is done after reading from the socket for the
      first time. Until then writing to the socket returns ENOTCONN.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      bb23c0ab
    • Marcel Holtmann's avatar
      Bluetooth: Add global deferred socket parameter · c4f912e1
      Marcel Holtmann authored
      The L2CAP and RFCOMM applications require support for authorization
      and the ability of rejecting incoming connection requests. The socket
      interface is not really able to support this.
      
      This patch does the ground work for a socket option to defer connection
      setup. Setting this option allows calling of accept() and then the
      first read() will trigger the final connection setup. Calling close()
      would reject the connection.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c4f912e1
    • Marcel Holtmann's avatar
      Bluetooth: Preparation for usage of SOL_BLUETOOTH · d58daf42
      Marcel Holtmann authored
      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: default avatarMarcel Holtmann <marcel@holtmann.org>
      d58daf42
    • Victor Shcherbatyuk's avatar
      Bluetooth: Fix issue with return value of rfcomm_sock_sendmsg() · 91aa35a5
      Victor Shcherbatyuk authored
      In case of connection failures the rfcomm_sock_sendmsg() should return
      an error and not a 0 value.
      Signed-off-by: default avatarVictor Shcherbatyuk <victor.shcherbatyuk@tomtom.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      91aa35a5
  2. 25 Feb, 2009 24 commits
  3. 24 Feb, 2009 1 commit