Skip to content

L
linux
Switch branch/tag
  1. 14 Jul, 2008 11 commits
    • 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
  3. 05 Jul, 2008 15 commits
  5. 04 Jul, 2008 14 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7