diff options
author | Marcel Holtmann <marcel@holtmann.org> | 2008-07-14 20:13:45 +0200 |
---|---|---|
committer | Marcel Holtmann <marcel@holtmann.org> | 2008-07-14 20:13:45 +0200 |
commit | 77db1980565626471a980f0d2d17299e4bd5e7a5 (patch) | |
tree | 93b71744c82fd3479d3c91033b871032de03049b /include/net/bluetooth/rfcomm.h | |
parent | 79d554a6976a295aa9212172b218f29ca71c3b3d (diff) | |
download | kernel_samsung_espresso10-77db1980565626471a980f0d2d17299e4bd5e7a5.zip kernel_samsung_espresso10-77db1980565626471a980f0d2d17299e4bd5e7a5.tar.gz kernel_samsung_espresso10-77db1980565626471a980f0d2d17299e4bd5e7a5.tar.bz2 |
[Bluetooth] Enforce security for outgoing RFCOMM connections
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 <marcel@holtmann.org>
Diffstat (limited to 'include/net/bluetooth/rfcomm.h')
-rw-r--r-- | include/net/bluetooth/rfcomm.h | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rfcomm.h index 98ec7a3..8c54ff3 100644 --- a/include/net/bluetooth/rfcomm.h +++ b/include/net/bluetooth/rfcomm.h @@ -181,6 +181,7 @@ struct rfcomm_dlc { u8 priority; u8 v24_sig; u8 mscex; + u8 out; u32 link_mode; |