aboutsummaryrefslogtreecommitdiffstats
path: root/include/net/bluetooth/rfcomm.h
diff options
context:
space:
mode:
authorMarcel Holtmann <marcel@holtmann.org>2008-07-14 20:13:45 +0200
committerMarcel Holtmann <marcel@holtmann.org>2008-07-14 20:13:45 +0200
commit77db1980565626471a980f0d2d17299e4bd5e7a5 (patch)
tree93b71744c82fd3479d3c91033b871032de03049b /include/net/bluetooth/rfcomm.h
parent79d554a6976a295aa9212172b218f29ca71c3b3d (diff)
downloadmrst-s0i3-test-77db1980565626471a980f0d2d17299e4bd5e7a5.tar.gz
mrst-s0i3-test-77db1980565626471a980f0d2d17299e4bd5e7a5.tar.xz
mrst-s0i3-test-77db1980565626471a980f0d2d17299e4bd5e7a5.zip
[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.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/include/net/bluetooth/rfcomm.h b/include/net/bluetooth/rfcomm.h
index 98ec7a32068..8c54ff37ad4 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;