linux.git/include/net/bluetooth/l2cap.h, branch v2.6.31

Bluetooth: Add basic constants for L2CAP ERTM support and use them

2009-06-08T12:50:00+00:00

This adds the basic constants required to add support for L2CAP Enhanced
Retransmission feature.

Based on a patch from Nathan Holstein 

Signed-off-by: Marcel Holtmann

Bluetooth: Use macro for L2CAP hint mask on receiving config request

2009-06-08T12:50:00+00:00

Using the L2CAP_CONF_HINT macro is easier to understand than using a
hardcoded 0x80 value.

Signed-off-by: Gustavo F. Padovan 
Signed-off-by: Marcel Holtmann

Bluetooth: Use macros for L2CAP channel identifiers

2009-06-08T12:49:59+00:00

Use macros instead of hardcoded numbers to make the L2CAP source code
more readable.

Signed-off-by: Gustavo F. Padovan 
Signed-off-by: Marcel Holtmann

Bluetooth: Ask upper layers for HCI disconnect reason

2009-02-27T05:14:43+00:00

Some of the qualification tests demand that in case of failures in L2CAP
the HCI disconnect should indicate a reason why L2CAP fails. This is a
bluntly layer violation since multiple L2CAP connections could be using
the same ACL and thus forcing a disconnect reason is not a good idea.

To comply with the Bluetooth test specification, the disconnect reason
is now stored in the L2CAP connection structure and every time a new
L2CAP channel is added it will set back to its default. So only in the
case where the L2CAP channel with the disconnect reason is really the
last one, it will propagated to the HCI layer.

The HCI layer has been extended with a disconnect indication that allows
it to ask upper layers for a disconnect reason. The upper layer must not
support this callback and in that case it will nicely default to the
existing behavior. If an upper layer like L2CAP can provide a disconnect
reason that one will be used to disconnect the ACL or SCO link.

No modification to the ACL disconnect timeout have been made. So in case
of Linux to Linux connection the initiator will disconnect the ACL link
before the acceptor side can signal the specific disconnect reason. That
is perfectly fine since Linux doesn't make use of this value anyway. The
L2CAP layer has a perfect valid error code for rejecting connection due
to a security violation. It is unclear why the Bluetooth specification
insists on having specific HCI disconnect reason.

Signed-off-by: Marcel Holtmann

Bluetooth: Add CID field to L2CAP socket address structure

2009-02-27T05:14:42+00:00

In preparation for L2CAP fixed channel support, the CID value of a
L2CAP connection needs to be accessible via the socket interface. The
CID is the connection identifier and exists as source and destination
value. So extend the L2CAP socket address structure with this field and
change getsockname() and getpeername() to fill it in.

The bind() and connect() functions have been modified to handle L2CAP
socket address structures of variable sizes. This makes them future
proof if additional fields need to be added.

Signed-off-by: Marcel Holtmann

Bluetooth: Request L2CAP fixed channel list if available

2009-02-27T05:14:42+00:00

If the extended features mask indicates support for fixed channels,
request the list of available fixed channels. This also enables the
fixed channel features bit so remote implementations can request
information about it. Currently only the signal channel will be
listed.

Signed-off-by: Marcel Holtmann

Bluetooth: Fix double L2CAP connection request

2009-02-27T05:14:41+00:00

If the remote L2CAP server uses authentication pending stage and
encryption is enabled it can happen that a L2CAP connection request is
sent twice due to a race condition in the connection state machine.

When the remote side indicates any kind of connection pending, then
track this state and skip sending of L2CAP commands for this period.

Signed-off-by: Marcel Holtmann

Bluetooth: Fix race condition with L2CAP information request

2009-02-27T05:14:41+00:00

When two L2CAP connections are requested quickly after the ACL link has
been established there exists a window for a race condition where a
connection request is sent before the information response has been
received. Any connection request should only be sent after an exchange
of the extended features mask has been finished.

Signed-off-by: Marcel Holtmann

Bluetooth: Replace L2CAP link mode with security level

2009-02-27T05:14:26+00:00

Change the L2CAP internals to use the new security levels and remove
the link mode details.

Signed-off-by: Marcel Holtmann

[Bluetooth] Fall back to L2CAP in basic mode

2007-10-22T09:59:43+00:00

In case the remote entity tries to negogiate retransmission or flow
control mode, reject it and fall back to basic mode.

Signed-off-by: Marcel Holtmann