aboutsummaryrefslogtreecommitdiff
path: root/include/net/bluetooth
AgeCommit message (Collapse)Author
2008-10-16include: replace __FUNCTION__ with __func__Harvey Harrison
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-09-09[Bluetooth] Reject L2CAP connections on an insecure ACL linkMarcel Holtmann
The Security Mode 4 of the Bluetooth 2.1 specification has strict authentication and encryption requirements. It is the initiators job to create a secure ACL link. However in case of malicious devices, the acceptor has to make sure that the ACL is encrypted before allowing any kind of L2CAP connection. The only exception here is the PSM 1 for the service discovery protocol, because that is allowed to run on an insecure ACL link. Previously it was enough to reject a L2CAP connection during the connection setup phase, but with Bluetooth 2.1 it is forbidden to do any L2CAP protocol exchange on an insecure link (except SDP). The new hci_conn_check_link_mode() function can be used to check the integrity of an ACL link. This functions also takes care of the cases where Security Mode 4 is disabled or one of the devices is based on an older specification. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2008-09-09[Bluetooth] Enforce correct authentication requirementsMarcel Holtmann
With the introduction of Security Mode 4 and Simple Pairing from the Bluetooth 2.1 specification it became mandatory that the initiator requires authentication and encryption before any L2CAP channel can be established. The only exception here is PSM 1 for the service discovery protocol (SDP). It is meant to be used without any encryption since it contains only public information. This is how Bluetooth 2.0 and before handle connections on PSM 1. For Bluetooth 2.1 devices the pairing procedure differentiates between no bonding, general bonding and dedicated bonding. The L2CAP layer wrongly uses always general bonding when creating new connections, but it should not do this for SDP connections. In this case the authentication requirement should be no bonding and the just-works model should be used, but in case of non-SDP connection it is required to use general bonding. If the new connection requires man-in-the-middle (MITM) protection, it also first wrongly creates an unauthenticated link key and then later on requests an upgrade to an authenticated link key to provide full MITM protection. With Simple Pairing the link key generation is an expensive operation (compared to Bluetooth 2.0 and before) and doing this twice during a connection setup causes a noticeable delay when establishing a new connection. This should be avoided to not regress from the expected Bluetooth 2.0 connection times. The authentication requirements are known up-front and so enforce them. To fulfill these requirements the hci_connect() function has been extended with an authentication requirement parameter that will be stored inside the connection information and can be retrieved by userspace at any time. This allows the correct IO capabilities exchange and results in the expected behavior. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2008-07-14[Bluetooth] Store remote modem status for RFCOMM TTYMarcel Holtmann
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 <denis.kenzior@trolltech.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2008-07-14[Bluetooth] Add timestamp support to L2CAP, RFCOMM and SCOMarcel Holtmann
Enable the common timestamp functionality that the network subsystem provides for L2CAP, RFCOMM and SCO sockets. It is possible to either use SO_TIMESTAMP or the IOCTLs to retrieve the timestamp of the current packet. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2008-07-14[Bluetooth] Export details about authentication requirementsMarcel Holtmann
With the Simple Pairing support, the authentication requirements are an explicit setting during the bonding process. Track and enforce the requirements and allow higher layers like L2CAP and RFCOMM to increase them if needed. This patch introduces a new IOCTL that allows to query the current authentication requirements. It is also possible to detect Simple Pairing support in the kernel this way. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2008-07-14[Bluetooth] Use ACL config stage to retrieve remote featuresMarcel Holtmann
The Bluetooth technology introduces new features on a regular basis and for some of them it is important that the hardware on both sides support them. For features like Simple Pairing it is important that the host stacks on both sides have switched this feature on. To make valid decisions, a config stage during ACL link establishment has been introduced that retrieves remote features and if needed also the remote extended features (known as remote host features) before signalling this link as connected. This change introduces full reference counting of incoming and outgoing ACL links and the Bluetooth core will disconnect both if no owner of it is present. To better handle interoperability during the pairing phase the disconnect timeout for incoming connections has been increased to 10 seconds. This is five times more than for outgoing connections. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2008-07-14[Bluetooth] Track status of remote Simple Pairing modeMarcel Holtmann
The Simple Pairing process can only be used if both sides have the support enabled in the host stack. The current Bluetooth specification has three ways to detect this support. If an Extended Inquiry Result has been sent during inquiry then it is safe to assume that Simple Pairing is enabled. It is not allowed to enable Extended Inquiry without Simple Pairing. During the remote name request phase a notification with the remote host supported features will be sent to indicate Simple Pairing support. Also the second page of the remote extended features can indicate support for Simple Pairing. For all three cases the value of remote Simple Pairing mode is stored in the inquiry cache for later use. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2008-07-14[Bluetooth] Track status of Simple Pairing modeMarcel Holtmann
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: Marcel Holtmann <marcel@holtmann.org>
2008-07-14[Bluetooth] Disable disconnect timer during Simple PairingMarcel Holtmann
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: Marcel Holtmann <marcel@holtmann.org>
2008-07-14[Bluetooth] Make use of the default link policy settingsMarcel Holtmann
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: Marcel Holtmann <marcel@holtmann.org>
2008-07-14[Bluetooth] Track connection packet type changesMarcel Holtmann
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: Marcel Holtmann <marcel@holtmann.org>
2008-07-14[Bluetooth] Disconnect when encryption gets disabledMarcel Holtmann
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: Marcel Holtmann <marcel@holtmann.org>
2008-07-14[Bluetooth] Enforce security for outgoing RFCOMM connectionsMarcel Holtmann
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>
2008-03-05bluetooth: Make hci_sock_cleanup() return voidTobias Klauser
hci_sock_cleanup() always returns 0 and its return value isn't used anywhere in the code. Compile-tested with 'make allyesconfig && make net/bluetooth/bluetooth.ko' Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Marcel Holtmann <marcel@holtmann.org>
2008-01-28[NET]: Remove FASTCALL macroHarvey Harrison
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 <harvey.harrison@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-10-22[Bluetooth] Add support for handling simple eSCO linksMarcel Holtmann
With the Bluetooth 1.2 specification the Extended SCO feature for better audio connections was introduced. So far the Bluetooth core wasn't able to handle any eSCO connections correctly. This patch adds simple eSCO support while keeping backward compatibility with older devices. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2007-10-22[Bluetooth] Fall back to L2CAP in basic modeMarcel Holtmann
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 <marcel@holtmann.org>
2007-10-22[Bluetooth] Retrieve L2CAP features mask on connection setupMarcel Holtmann
The Bluetooth 1.2 specification introduced a specific features mask value to interoperate with newer versions of the specification. So far this piece of information was never needed, but future extensions will rely on it. This patch adds a generic way to retrieve this information only once per connection setup. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2007-10-22[Bluetooth] Remove global conf_mtu variable from L2CAPMarcel Holtmann
After the change to the L2CAP configuration parameter handling the global conf_mtu variable is no longer needed and so remove it. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2007-10-22[Bluetooth] Switch from OGF+OCF to using only opcodesMarcel Holtmann
The Bluetooth HCI commands are divided into logical OGF groups for easier identification of their purposes. While this still makes sense for the written specification, its makes the code only more complex and harder to read. So instead of using separate OGF and OCF values to identify the commands, use a common 16-bit opcode that combines both values. As a side effect this also reduces the complexity of OGF and OCF calculations during command header parsing. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2007-07-31[BLUETOOTH] l2cap: endianness annotationsAl Viro
no code changes, just documenting existing types Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-07-11[Bluetooth] Add basics to better support and handle eSCO linksMarcel Holtmann
To better support and handle eSCO links in the future a bunch of constants needs to be added and some basic routines need to be updated. This is the initial step. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2007-07-11[Bluetooth] Keep rfcomm_dev on the list until it is freedVille Tervo
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 <ville.tervo@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2007-07-11[Bluetooth] Add hci_recv_fragment() helper functionMarcel Holtmann
Most drivers must handle fragmented HCI data packets and events. This patch adds a generic function for their reassembly to the Bluetooth core layer and thus allows to shrink the complexity of the drivers. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2007-05-24[Bluetooth] Fix L2CAP configuration parameter handlingMarcel Holtmann
The L2CAP configuration parameter handling was missing the support for rejecting unknown options. The capability to reject unknown options is mandatory since the Bluetooth 1.2 specification. This patch implements its and also simplifies the parameter parsing. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2007-04-25[BLUETOOTH]: Introduce skb->data accessor methods for hci_{acl,event,sco}_hdrArnaldo Carvalho de Melo
For consistency with other skb data accessors, reducing the number of direct accesses to skb->data. Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2006-12-13[PATCH] hci endianness annotationsAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-02[BLUETOOTH]: rfcomm endianness annotationsAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-10-15[Bluetooth] Support concurrent connect requestsMarcel Holtmann
Most Bluetooth chips don't support concurrent connect requests, because this would involve a multiple baseband page with only one radio. In the case an upper layer like L2CAP requests a concurrent connect these chips return the error "Command Disallowed" for the second request. If this happens it the responsibility of the Bluetooth core to queue the request and try again after the previous connect attempt has been completed. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2006-09-28[Bluetooth] Support create connection cancel commandMarcel Holtmann
In case of non-blocking connects it is possible that the last user of an ACL link quits before the connection has been fully established. This will lead to a race condition where the internal state of a connection is closed, but the actual link has been established and is active. In case of Bluetooth 1.2 and later devices it is possible to call create connection cancel to abort the connect. For older devices the disconnect timer will be used to trigger the needed disconnect. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2006-09-28[Bluetooth] Read local version information on device initMarcel Holtmann
The local version information are needed to identify certain feature sets of devices. They must be read on device init and stored for later use. It is also possible to access them through the device model. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2006-09-28[Bluetooth] Handle command complete event for exit periodic inquiryMarcel Holtmann
The command complete event of the exit periodic inquiry command must clear the HCI_INQUIRY flag and finish the HCI request. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2006-09-28[Bluetooth] Add HCI device identifier for SDIO cardsMarcel Holtmann
This patch assigns the next free HCI device identifier to Bluetooth devices based on the SDIO interface. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2006-09-28[Bluetooth] Integrate low-level connections into the driver modelMarcel Holtmann
This patch integrates the low-level connections (ACL and SCO) into the driver model. Every connection is presented as device with the parent set to its host controller device. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2006-07-03[Bluetooth] Use real devices for host controllersMarcel Holtmann
This patch converts the Bluetooth class devices into real devices. The Bluetooth class is kept and the driver core provides the appropriate symlinks for backward compatibility. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2006-07-03[Bluetooth] Add platform device for virtual and serial devicesMarcel Holtmann
This patch adds a generic Bluetooth platform device that can be used as parent device by virtual and serial devices. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2006-07-03[Bluetooth] Add automatic sniff mode supportMarcel Holtmann
This patch introduces the automatic sniff mode feature. This allows the host to switch idle connections into sniff mode to safe power. Signed-off-by: Ulisses Furquim <ulissesf@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2006-07-03[Bluetooth] Correct SCO buffer size on requestMarcel Holtmann
This patch introduces a quirk that allows the drivers to tell the host to correct the SCO buffer size values. Signed-off-by: Olivier Galibert <galibert@pobox.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2006-02-13[Bluetooth] Reduce L2CAP MTU for RFCOMM connectionsMarcel Holtmann
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 <marcel@holtmann.org>
2005-11-08[Bluetooth]: Remove the usage of /proc completelyMarcel Holtmann
This patch removes all relics of the /proc usage from the Bluetooth subsystem core and its upper layers. All the previous information are now available via /sys/class/bluetooth through appropriate functions. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-11-08[Bluetooth]: Add endian annotations to the coreMarcel Holtmann
This patch adds the endian annotations to the Bluetooth core. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-10-28[Bluetooth] Make more functions staticMarcel Holtmann
This patch makes another bunch of functions static. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2005-10-28[Bluetooth] Move CRC table into RFCOMM coreMarcel Holtmann
This patch moves rfcomm_crc_table[] into the RFCOMM core, because there is no need to keep it in a separate file. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2005-10-08[PATCH] gfp flags annotations - part 1Al Viro
- added typedef unsigned int __nocast gfp_t; - replaced __nocast uses for gfp flags with gfp_t - it gives exactly the same warnings as far as sparse is concerned, doesn't change generated code (from gcc point of view we replaced unsigned int with typedef) and documents what's going on far better. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-13[Bluetooth] Add support for extended inquiry responsesMarcel Holtmann
This patch adds the handling of the extended inquiry responses and inserts them into the inquiry cache. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2005-08-29[NET]: Store skb->timestamp as offset to a base timestampPatrick McHardy
Reduces skb size by 8 bytes on 64-bit. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-29[Bluetooth]: Move packet type into the SKB control bufferMarcel Holtmann
This patch moves the usage of packet type into the SKB control buffer. After this patch it is now possible to shrink the sk_buff structure and redefine its pkt_type. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-29[Bluetooth]: Fix sparse warnings (__nocast type)Victor Fusco
This patch fixes the sparse warnings "implicit cast to nocast type" for the priority or gfp_mask parameters of the memory allocations. Signed-off-by: Victor Fusco <victor@cetuc.puc-rio.br> Signed-off-by: Domen Puncer <domen@coderock.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-29[Bluetooth]: Implement RFCOMM remote port negotiationJ. Suter
This patch implements the remote port negotiation (RPN) of the RFCOMM protocol for Bluetooth. Signed-off-by: J. Suter <jsuter@hardwave.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>