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

bluetooth: rfcomm_init bug fix

2009-08-03T20:24:39+00:00

rfcomm tty may be used before rfcomm_tty_driver initilized,
The problem is that now socket layer init before tty layer, if userspace
program do socket callback right here then oops will happen.

reporting in:
http://marc.info/?l=linux-bluetooth&m=124404919324542&w=2

make 3 changes:
1. remove #ifdef in rfcomm/core.c,
make it blank function when rfcomm tty not selected in rfcomm.h

2. tune the rfcomm_init error patch to ensure
tty driver initilized before rfcomm socket usage.

3. remove __exit for rfcomm_cleanup_sockets
because above change need call it in a __init function.

Reported-by: Oliver Hartkopp 
Tested-by: Oliver Hartkopp 
Signed-off-by: Dave Young 
Signed-off-by: David S. Miller

Bluetooth: Pause RFCOMM TX when encryption drops

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

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 

Signed-off-by: Marcel Holtmann

Bluetooth: Replace RFCOMM link mode with security level

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

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

Signed-off-by: Marcel Holtmann

Bluetooth: Add support for deferring RFCOMM connection setup

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

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: Marcel Holtmann

[Bluetooth] Store remote modem status for RFCOMM TTY

2008-07-14T18:13:52+00:00

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: Denis Kenzior 
Signed-off-by: Marcel Holtmann

[Bluetooth] Enforce security for outgoing RFCOMM connections

2008-07-14T18:13:45+00:00

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: Marcel Holtmann

[NET]: Remove FASTCALL macro

2008-01-28T22:57:23+00:00

X86_32 was the last user of the FASTCALL macro, now that it
uses regparm(3) by default, this macro expands to nothing.

Signed-off-by: Harvey Harrison 
Signed-off-by: David S. Miller

[Bluetooth] Keep rfcomm_dev on the list until it is freed

2007-07-11T05:06:51+00:00

This patch changes the RFCOMM TTY release process so that the TTY is kept
on the list until it is really freed. A new device flag is used to keep
track of released TTYs.

Signed-off-by: Ville Tervo 
Signed-off-by: Marcel Holtmann

[BLUETOOTH]: rfcomm endianness annotations

2006-12-03T05:21:29+00:00

Signed-off-by: Al Viro 
Signed-off-by: David S. Miller

[Bluetooth] Reduce L2CAP MTU for RFCOMM connections

2006-02-13T10:39:57+00:00

This patch reduces the default L2CAP MTU for all RFCOMM connections
from 1024 to 1013 to improve the interoperability with some broken
RFCOMM implementations. To make this more flexible the L2CAP MTU
becomes also a module parameter and so it can changed at runtime.

Signed-off-by: Marcel Holtmann