1. 14 Jul, 2008 24 commits
    • Marcel Holtmann's avatar
      [Bluetooth] Signal user-space for HIDP and BNEP socket errors · ec8dab36
      Marcel Holtmann authored
      When using the HIDP or BNEP kernel support, the user-space needs to
      know if the connection has been terminated for some reasons. Wake up
      the application if that happens. Otherwise kernel and user-space are
      no longer on the same page and weird behaviors can happen.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      ec8dab36
    • Marcel Holtmann's avatar
      [Bluetooth] Move pending packets from RFCOMM socket to TTY · a0c22f22
      Marcel Holtmann authored
      When an incoming RFCOMM socket connection gets converted into a TTY,
      it can happen that packets are lost. This mainly happens with the
      Handsfree profile where the remote side starts sending data right
      away. The problem is that these packets are in the socket receive
      queue. So when creating the TTY make sure to copy all pending packets
      from the socket receive queue to a private queue inside the TTY.
      
      To make this actually work, the flow control on the newly created TTY
      will be disabled and only enabled again when the TTY is opened by an
      application. And right before that, the pending packets will be put
      into the TTY flip buffer.
      Signed-off-by: default avatarDenis Kenzior <denis.kenzior@trolltech.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a0c22f22
    • Marcel Holtmann's avatar
      [Bluetooth] Store remote modem status for RFCOMM TTY · 8b6b3da7
      Marcel Holtmann authored
      When switching a RFCOMM socket to a TTY, the remote modem status might
      be needed later. Currently it is lost since the original configuration
      is done via the socket interface. So store the modem status and reply
      it when the socket has been converted to a TTY.
      Signed-off-by: default avatarDenis Kenzior <denis.kenzior@trolltech.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      8b6b3da7
    • Marcel Holtmann's avatar
      [Bluetooth] Use non-canonical TTY by default for RFCOMM · ca37bdd5
      Marcel Holtmann authored
      While the RFCOMM TTY emulation can act like a real serial port, in
      reality it is not used like this. So to not mess up stupid applications,
      use the non-canonical mode by default.
      Signed-off-by: default avatarDenis Kenzior <denis.kenzior@trolltech.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      ca37bdd5
    • Marcel Holtmann's avatar
      [Bluetooth] Update Bluetooth core version number · 78c6a174
      Marcel Holtmann authored
      With all the Bluetooth 2.1 changes and the support for Simple Pairing,
      it is important to update the Bluetooth core version number.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      78c6a174
    • Marcel Holtmann's avatar
      [Bluetooth] Use a more unique bus name for connections · 7d0db0a3
      Marcel Holtmann authored
      When attaching Bluetooth low-level connections to the bus, the bus name
      is constructed from the remote address since at that time the connection
      handle is not assigned yet. This has worked so far, but also caused a
      lot of troubles. It is better to postpone the creation of the sysfs
      entry to the time when the connection actually has been established
      and then use its connection handle as unique identifier.
      
      This also fixes the case where two different adapters try to connect
      to the same remote device.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      7d0db0a3
    • Marcel Holtmann's avatar
      [Bluetooth] Add support for TIOCOUTQ and TIOCINQ ioctls · 43cbeee9
      Marcel Holtmann authored
      Almost every protocol family supports the TIOCOUTQ and TIOCINQ ioctls
      and even Bluetooth could make use of them. When implementing audio
      streaming and integration with GStreamer or PulseAudio they will allow
      a better timing and synchronization.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      43cbeee9
    • Marcel Holtmann's avatar
      [Bluetooth] Add timestamp support to L2CAP, RFCOMM and SCO · 3241ad82
      Marcel Holtmann authored
      Enable the common timestamp functionality that the network subsystem
      provides for L2CAP, RFCOMM and SCO sockets. It is possible to either
      use SO_TIMESTAMP or the IOCTLs to retrieve the timestamp of the
      current packet.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      3241ad82
    • Marcel Holtmann's avatar
      [Bluetooth] Export details about authentication requirements · 40be492f
      Marcel Holtmann authored
      With the Simple Pairing support, the authentication requirements are
      an explicit setting during the bonding process. Track and enforce the
      requirements and allow higher layers like L2CAP and RFCOMM to increase
      them if needed.
      
      This patch introduces a new IOCTL that allows to query the current
      authentication requirements. It is also possible to detect Simple
      Pairing support in the kernel this way.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      40be492f
    • Marcel Holtmann's avatar
      [Bluetooth] Initiate authentication during connection establishment · f8558555
      Marcel Holtmann authored
      With Bluetooth 2.1 and Simple Pairing the requirement is that any new
      connection needs to be authenticated and that encryption has been
      switched on before allowing L2CAP to use it. So make sure that all
      the requirements are fulfilled and otherwise drop the connection with
      a minimal disconnect timeout of 10 milliseconds.
      
      This change only affects Bluetooth 2.1 devices and Simple Pairing
      needs to be enabled locally and in the remote host stack. The previous
      changes made sure that these information are discovered before any
      kind of authentication and encryption is triggered.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f8558555
    • Marcel Holtmann's avatar
      [Bluetooth] Use ACL config stage to retrieve remote features · 769be974
      Marcel Holtmann authored
      The Bluetooth technology introduces new features on a regular basis
      and for some of them it is important that the hardware on both sides
      support them. For features like Simple Pairing it is important that
      the host stacks on both sides have switched this feature on. To make
      valid decisions, a config stage during ACL link establishment has been
      introduced that retrieves remote features and if needed also the remote
      extended features (known as remote host features) before signalling
      this link as connected.
      
      This change introduces full reference counting of incoming and outgoing
      ACL links and the Bluetooth core will disconnect both if no owner of it
      is present. To better handle interoperability during the pairing phase
      the disconnect timeout for incoming connections has been increased to
      10 seconds. This is five times more than for outgoing connections.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      769be974
    • Marcel Holtmann's avatar
      [Bluetooth] Export remote Simple Pairing mode via sysfs · a8bd28ba
      Marcel Holtmann authored
      Since the remote Simple Pairing mode is stored together with the
      inquiry cache, it makes sense to show it together with the other
      information.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a8bd28ba
    • Marcel Holtmann's avatar
      [Bluetooth] Track status of remote Simple Pairing mode · 41a96212
      Marcel Holtmann authored
      The Simple Pairing process can only be used if both sides have the
      support enabled in the host stack. The current Bluetooth specification
      has three ways to detect this support.
      
      If an Extended Inquiry Result has been sent during inquiry then it
      is safe to assume that Simple Pairing is enabled. It is not allowed
      to enable Extended Inquiry without Simple Pairing. During the remote
      name request phase a notification with the remote host supported
      features will be sent to indicate Simple Pairing support. Also the
      second page of the remote extended features can indicate support for
      Simple Pairing.
      
      For all three cases the value of remote Simple Pairing mode is stored
      in the inquiry cache for later use.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      41a96212
    • Marcel Holtmann's avatar
      [Bluetooth] Track status of Simple Pairing mode · 333140b5
      Marcel Holtmann authored
      The Simple Pairing feature is optional and needs to be enabled by the
      host stack first. The Linux kernel relies on the Bluetooth daemon to
      either enable or disable it, but at any time it needs to know the
      current state of the Simple Pairing mode. So track any changes made
      by external entities and store the current mode in the HCI device
      structure.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      333140b5
    • Marcel Holtmann's avatar
      [Bluetooth] Disable disconnect timer during Simple Pairing · 0493684e
      Marcel Holtmann authored
      During the Simple Pairing process the HCI disconnect timer must be
      disabled. The way to do this is by holding a reference count of the
      HCI connection. The Simple Pairing process on both sides starts with
      an IO Capabilities Request and ends with Simple Pairing Complete.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      0493684e
    • Marcel Holtmann's avatar
      [Bluetooth] Update class of device value whenever possible · c7bdd502
      Marcel Holtmann authored
      The class of device value can only be retrieved via inquiry or during
      an incoming connection request. Outgoing connections can't ask for the
      class of device. To compensate for this the value is stored and copied
      via the inquiry cache, but currently only updated via inquiry. This
      update should also happen during an incoming connection request.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      c7bdd502
    • Marcel Holtmann's avatar
      [Bluetooth] Some cleanups for HCI event handling · f383f275
      Marcel Holtmann authored
      Some minor cosmetic cleanups to the HCI event handling to make the
      code easier to read and understand.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f383f275
    • Marcel Holtmann's avatar
      [Bluetooth] Make use of the default link policy settings · e4e8e37c
      Marcel Holtmann authored
      The Bluetooth specification supports the default link policy settings
      on a per host controller basis. For every new connection the link
      manager would then use these settings. It is better to use this instead
      of bothering the controller on every connection setup to overwrite the
      default settings.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      e4e8e37c
    • Marcel Holtmann's avatar
      [Bluetooth] Track connection packet type changes · a8746417
      Marcel Holtmann authored
      The connection packet type can be changed after the connection has been
      established and thus needs to be properly tracked to ensure that the
      host stack has always correct and valid information about it.
      
      On incoming connections the Bluetooth core switches the supported packet
      types to the configured list for this controller. However the usefulness
      of this feature has been questioned a lot. The general consent is that
      every Bluetooth host stack should enable as many packet types as the
      hardware actually supports and leave the decision to the link manager
      software running on the Bluetooth chip.
      
      When running on Bluetooth 2.0 or later hardware, don't change the packet
      type for incoming connections anymore. This hardware likely supports
      Enhanced Data Rate and thus leave it completely up to the link manager
      to pick the best packet type.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a8746417
    • 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 1 commit