| 565766b087a6d6ff257f5b79c8ceda0188c9169f |
|
25-Sep-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Rename sco_param_wideband table to esco_param_msbc
The sco_param_wideband table represents the eSCO parameters for
specifically mSBC encoding. This patch renames the table to the more
descriptive esco_param_msbc name.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| c7da579763f29cf45a861ad4c339aba590d8b80d |
|
24-Sep-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Add retransmission effort into SCO parameter table
It is expected that new parameter combinations will have the
retransmission effort value different between some entries (mainly
because of the new S4 configuration added by HFP 1.7), so it makes sense
to move it into the table instead of having it hard coded based on the
selected SCO_AIRMODE_*.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| d41c15cf95bd91b9c333f6f749670e22c8a47ad9 |
|
24-Sep-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix reason code used for rejecting SCO connections
The core specification defines valid values for the
HCI_Reject_Synchronous_Connection_Request command to be 0x0D-0x0F. So
far the code has been using HCI_ERROR_REMOTE_USER_TERM (0x13) which is
not a valid value and is therefore being rejected by some controllers:
> HCI Event: Connect Request (0x04) plen 10
bdaddr 40:6F:2A:6A:E5:E0 class 0x000000 type eSCO
< HCI Command: Reject Synchronous Connection (0x01|0x002a) plen 7
bdaddr 40:6F:2A:6A:E5:E0 reason 0x13
Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
Reject Synchronous Connection (0x01|0x002a) status 0x12 ncmd 1
Error: Invalid HCI Command Parameters
This patch introduces a new define for a value from the valid range
(0x0d == Connection Rejected Due To Limited Resources) and uses it
instead for rejecting incoming connections.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 48e68ff5e55af6907d3f90233e5c4d5601a628a6 |
|
23-Sep-2014 |
Bernhard Thaler <bernhard.thaler@r-it.at> |
Bluetooth: Check for SCO type before setting retransmission effort
SCO connection cannot be setup to devices that do not support retransmission.
Patch based on http://permalink.gmane.org/gmane.linux.bluez.kernel/7779 and
adapted for this kernel version.
Code changed to check SCO/eSCO type before setting retransmission effort
and max. latency. The purpose of the patch is to support older devices not
capable of eSCO.
Tested on Blackberry 655+ headset which does not support retransmission.
Credits go to Alexander Sommerhuber.
Signed-off-by: Bernhard Thaler <bernhard.thaler@r-it.at>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 839035a7b3acd17a6f739b1fb50298e9499d3fa4 |
|
18-Aug-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Move clock offset reading into hci_disconnect()
To give all hci_disconnect() users the advantage of getting the clock
offset read automatically this patch moves the necessary code from
hci_conn_timeout() into hci_disconnect(). This way we pretty much always
update the clock offset when disconnecting.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| e3b679d56caa2bc555dee646a6ac5861631e7a28 |
|
18-Aug-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Update hci_disconnect() to return an error value
We'll soon use hci_disconnect() from places that are interested to know
whether the hci_send_cmd() really succeeded or not. This patch updates
hci_disconnect() to pass on any error returned from hci_send_cmd().
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| bcbb655a180344d8004ede669228992bff1921e4 |
|
18-Aug-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Remove hci_conn_hold/drop from hci_chan
We can't have hci_chan contribute to the "active" reference counting of
the hci_conn since otherwise the connection would never get dropped when
there are no more users (since hci_chan would be counted as a user).
This patch removes hold() when creating the hci_chan and drop() when
destroying it.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| f94b665dcf15324f5ac8aa639e47be0829b6409d |
|
17-Aug-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Ignore incoming data after initiating disconnection
When hci_chan_del is called the disconnection routines get scheduled
through a workqueue. If there's any incoming ACL data before the
routines get executed there's a chance that a new hci_chan is created
and the disconnection never happens. This patch adds a new hci_conn flag
to indicate that we're in the process of driving the connection down. We
set the flag in hci_chan_del and check for it in hci_chan_create so that
no new channels are created for the same connection.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| b3ff670a44cc34c01e78900c42255511e4f232e6 |
|
17-Aug-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Set disc_timeout to 0 when calling hci_chan_del
The hci_chan_del() function is used in scenarios where we've decided we
want to get rid of the underlying baseband link. It makes therefore
sense to force the disc_timeout to 0 so that the disconnection routines
are immediately scheduled.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 6c388d32ec1b9fcc2f2404fb5e9b3b0096be5de9 |
|
17-Aug-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix hci_conn reference counting with hci_chan
The hci_chan_del() function was doing a hci_conn_drop() but there was no
matching hci_conn_hold() in the hci_chan_create() function. Furthermore,
as the hci_chan struct holds a pointer to the hci_conn there should be
proper use of hci_conn_get/put. This patch fixes both issues so that
hci_chan does correct reference counting of the hci_conn object.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| f8aaf9b65a77267f749c1af641e46c3457d50701 |
|
17-Aug-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix using hci_conn_get() for hci_conn pointers
Wherever we keep hci_conn pointers around we should be using
hci_conn_get/put to ensure that they stay valid. This patch fixes
all places violating against the principle currently.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| f161dd4122ffa73e4e12000309dca65bec80d416 |
|
15-Aug-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix hci_conn reference counting for auto-connections
Recently the LE passive scanning and auto-connections feature was
introduced. It uses the hci_connect_le() API which returns a hci_conn
along with a reference count to that object. All previous users would
tie this returned reference to some existing object, such as an L2CAP
channel, and there'd be no leaked references this way. For
auto-connections however the reference was returned but not stored
anywhere, leaving established connections with one higher reference
count than they should have.
Instead of playing special tricks with hci_conn_hold/drop this patch
associates the returned reference from hci_connect_le() with the object
that in practice does own this reference, i.e. the hci_conn_params
struct that caused us to initiate a connection in the first place. Once
the connection is established or fails to establish this reference is
removed appropriately.
One extra thing needed is to call hci_pend_le_actions_clear() before
calling hci_conn_hash_flush() so that the reference is cleared before
the hci_conn objects are fully removed.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 27f70f3e628c82362def60eb0af79d2129a51da2 |
|
21-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Prefer sizeof(*ptr) when allocating memory
It's safer practice to use sizeof(*ptr) instead of sizeof(ptr_type) when
allocating memory in case the type changes. This also fixes the
following style of warnings from static analyzers:
CHECK: Prefer kzalloc(sizeof(*ie)...) over kzalloc(sizeof(struct inquiry_entry)...)
+ ie = kzalloc(sizeof(struct inquiry_entry), GFP_KERNEL);
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| beb19e4c079d626bf0502fbb65bd7c9891a10c2e |
|
18-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Use EOPNOTSUPP instead of ENOTSUPP
The EOPNOTSUPP and ENOTSUPP errors are very similar in meaning, but
ENOTSUPP is a fairly new addition to POSIX. Not all libc versions know
about the value the kernel uses for ENOTSUPP so it's better to use
EOPNOTSUPP to ensure understandable error messages.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 977f8fce0279e5f96dc5c5068610d60b9ae94802 |
|
17-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Introduce a flag to track who really initiates authentication
Even though our side requests authentication, the original action that
caused it may be remotely triggered, such as an incoming L2CAP or RFCOMM
connect request. To track this information introduce a new hci_conn flag
called HCI_CONN_AUTH_INITIATOR.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| e7cafc45258c852c5176cd421615846e79a3d307 |
|
17-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Pass initiator/acceptor information to hci_conn_security()
We're interested in whether an authentication request is because of a
remote or local action. So far hci_conn_security() has been used both
for incoming and outgoing actions (e.g. RFCOMM or L2CAP connect
requests) so without some modifications it cannot know which peer is
responsible for requesting authentication.
This patch adds a new "bool initiator" parameter to hci_conn_security()
to indicate which side is responsible for the request and updates the
current users to pass this information correspondingly.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| a5c4e309b9f23b9de5475029b2cb1641ec293137 |
|
16-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Add a role parameter to hci_conn_add()
We need to be able to track slave vs master LE connections in
hci_conn_hash, and to be able to do that we need to know the role of the
connection by the time hci_conn_add_has() is called. This means in
practice the hci_conn_add() call that creates the hci_conn_object.
This patch adds a new role parameter to hci_conn_add() function to give
the object its initial role value, and updates the callers to pass the
appropriate role to it. Since the function now takes care of
initializing both conn->role and conn->out values we can remove some
other unnecessary assignments.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| e804d25d4a07c0ff9e5e1c58ea5ee67232aa9af8 |
|
16-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Use explicit role instead of a bool in function parameters
To make the code more understandable it makes sense to use the new HCI
defines for connection role instead of a "bool master" parameter. This
makes it immediately clear when looking at the function calls what the
last parameter is describing.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 40bef302f6323d1ee6fb3dc0e62edb0f446d0339 |
|
16-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Convert HCI_CONN_MASTER flag to a conn->role variable
Having a dedicated u8 role variable in the hci_conn struct greatly
simplifies tracking of the role, since this is the native way that it's
represented on the HCI level.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| e8bb6b9739e2e80e0e413f56816af3871388cfe8 |
|
08-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix advertising and active scanning co-existence
Many controllers allow simultaneous active scanning and advertising
(e.g. Intel and Broadcom) but some do not (e.g. CSR). It's therefore
safest to implement mutual exclusion of these states in the kernel.
This patch ensures that the two states are never entered simultaneously.
Extra precaution needs to be taken for outgoing connection attempts in
slave role (i.e. through directed advertising) in which case the
operation that came first has precedence and the one that comes after
gets a rejection.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 376f54c171674ac1f9a2eefe67d413db4836d25a |
|
08-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Stop advertising always before initiating a connection
Most controllers do not support advertising while initiating an LE
connection. We also have to first disable current advertising if the
initiation is going to happen through direct advertising. Therefore,
simply stop advertising as the first thing when starting to issue
commands to establish an LE connection.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 5ce194c4a751ac603966dd1567b62035a7dfbf89 |
|
08-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Use real advertising state to random address update decision
Now that we have a flag for tracking the real advertising state we
should use that to determine whether it's safe to update the random
address or not. The couple of places that were clearing the flag due to
a pending request need to be updated too.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| cdd6275e510bd86c44d3fc85a78306f514bbac9a |
|
07-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Pass desired connection role to hci_connect_le()
If we have both LE scanning and advertising simultaneously enabled we
need a way to tell hci_connect_le() in which role to initiate a
connection. This patch adds a new parameter to the function to give it
the necessary information. For auto-connect and mgmt_pair_device we
always use master role, whereas for L2CAP users (in practice sockets) we
use slave role whenever HCI_ADVERTISING is set and master role
otherwise.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| d93375a82da10cb023afc945fa18471bf3c41704 |
|
07-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Remove auth_type parameter from hci_connect_le()
The auth_type value which gets assigned to hci_conn->auth_type is
something that's only used for BR/EDR connections and is of no value for
LE connections. It makes therefore little sense to pass it to the
hci_connect_le() function. This patch removes the parameter from the
function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 09ae260ba452c2ed36ec295941a58cb75db213ed |
|
06-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Use lower timeout for LE auto-connections
When we establish connections as a consequence of receiving an
advertising report it makes no sense to wait the normal 20 second LE
connection timeout. This patch modifies the hci_connect_le function to
take an extra timeout value and uses a lower 2 second timeout for the
auto-connection case. This timeout is intentionally chosen to be just a
bit higher than the 1.28 second timeout that High Duty Cycle Advertising
uses.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 7d6ca6939cb2f701204317cbab15af1b98f7f501 |
|
02-Jul-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Make hci_le_conn_update return the store hint
The caller of hci_le_conn_update is directly interested in knowing what
the best value is for the store_hint parameter of the corresponding
mgmt event. Since hci_le_conn_update knows whether there were stored
parameters that were updated or not we can have it return an initial
store_hint value to the caller.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 04fb7d9066dd9173ef0d4ccea8fe3bb59bd94605 |
|
30-Jun-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Provide defaults for LE connection latency and timeout
Store the connection latency and supervision timeout default values
with all the other controller defaults. And when needed use them
for new connections.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 037fc415bce5ac7604ac52216ec03d011f81e5b0 |
|
29-Jun-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Use LE connection parameters if known
When the LE connection parameters for connection latency and
supervision timeout are known, then use then. If they are not
know fallback to defaults.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| f044eb0524a02ea7f921c9234fbdba43290da1e2 |
|
29-Jun-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Store latency and supervision timeout in connection params
When the slave updates the connection parameters, store also the
connection latency and supervision timeout information in the
internal list of connection parameters for known devices.
Having these values available allowes the auto-connection
procedure to use the correct values from the beginning without
having to request an update on every connection establishment.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| fee746b0babf128a50ece050ee6e63003ebb5ae1 |
|
29-Jun-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Restrict access for raw-only controllers
Bluetooth controllers that are marked for raw-only usage can only be
used with user channel access. Any other operation should be rejected.
This simplifies the whole raw-only support since it now depends on
the fact that the controller is marked with HCI_QUIRK_RAW_DEVICE and
runtime raw access is restricted to user channel operation.
The kernel internal processing of HCI commands and events is designed
around the case that either the kernel has full control over the device
or that the device is driven from userspace. This now makes a clear
distinction between these two possible operation modes.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| df935429be40b02568d4bcf9ebfacf8011b85a85 |
|
27-Jun-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Send HCI_Read_Clock_Offset before disconnecting
When the connection is in master role and it is going to be
disconnected based on the disconnection timeout, then send
the HCI_Read_Clock_Offset command in an attempt to update the
clock offset value in the inquiry cache.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 40051e4686d6fa8743a38933727604f75bef05cf |
|
27-Jun-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Remove unneeded hci_conn_disconnect abstraction
The abstraction of disconnect operation via hci_conn_disconnect is not
needed and it does not add any readability. Handle the difference of
AMP physical channels and BR/EDR/LE connection in the timeout callback.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| a2b1976b8e0184635a1119f8511fc3e68902e429 |
|
27-Jun-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Remove reason parameter from hci_amp_disconn function
The hci_amp_disconn function is a local function and there is no
need for a reason parameter. That one can be retrieved from the
hci_conn object easily.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 4dae27983eaaee15c6867561eb2c8d7b2d28d6cc |
|
24-Jun-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Convert hci_conn->link_mode into flags
Since the link_mode member of the hci_conn struct is a bit field and we
already have a flags member as well it makes sense to merge these two
together. This patch moves all used link_mode bits into corresponding
flags. To keep backwards compatibility with user space we still need to
provide a get_link_mode() helper function for the ioctl's that expect a
link_mode style value.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 1d56dc4f5f7cdf0ba99062d974b7586a28fc5cf4 |
|
17-Jun-2014 |
Lukasz Rymanowski <lukasz.rymanowski@tieto.com> |
Bluetooth: Fix for ACL disconnect when pairing fails
When pairing fails hci_conn refcnt drops below zero. This cause that
ACL link is not disconnected when disconnect timeout fires.
Probably this is because l2cap_conn_del calls l2cap_chan_del for each
channel, and inside l2cap_chan_del conn is dropped. After that loop
hci_chan_del is called which also drops conn.
Anyway, as it is desrcibed in hci_core.h, it is known that refcnt
drops below 0 sometimes and it should be fine. If so, let disconnect
link when hci_conn_timeout fires and refcnt is 0 or below. This patch
does it.
This affects PTS test SM_TC_JW_BV_05_C
Logs from scenario:
[69713.706227] [6515] pair_device:
[69713.706230] [6515] hci_conn_add: hci0 dst 00:1b:dc:06:06:22
[69713.706233] [6515] hci_dev_hold: hci0 orig refcnt 8
[69713.706235] [6515] hci_conn_init_sysfs: conn ffff88021f65a000
[69713.706239] [6515] hci_req_add_ev: hci0 opcode 0x200d plen 25
[69713.706242] [6515] hci_prepare_cmd: skb len 28
[69713.706243] [6515] hci_req_run: length 1
[69713.706248] [6515] hci_conn_hold: hcon ffff88021f65a000 orig refcnt 0
[69713.706251] [6515] hci_dev_put: hci0 orig refcnt 9
[69713.706281] [8909] hci_cmd_work: hci0 cmd_cnt 1 cmd queued 1
[69713.706288] [8909] hci_send_frame: hci0 type 1 len 28
[69713.706290] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 28
[69713.706316] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.706382] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.711664] [8909] hci_rx_work: hci0
[69713.711668] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 6
[69713.711680] [8909] hci_rx_work: hci0 Event packet
[69713.711683] [8909] hci_cs_le_create_conn: hci0 status 0x00
[69713.711685] [8909] hci_sent_cmd_data: hci0 opcode 0x200d
[69713.711688] [8909] hci_req_cmd_complete: opcode 0x200d status 0x00
[69713.711690] [8909] hci_sent_cmd_data: hci0 opcode 0x200d
[69713.711695] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.711744] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.818875] [8909] hci_rx_work: hci0
[69713.818889] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 21
[69713.818913] [8909] hci_rx_work: hci0 Event packet
[69713.818917] [8909] hci_le_conn_complete_evt: hci0 status 0x00
[69713.818922] [8909] hci_send_to_control: len 19
[69713.818927] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.818938] [8909] hci_conn_add_sysfs: conn ffff88021f65a000
[69713.818975] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800
[69713.818981] [6515] hci_sock_recvmsg: sock ffff88005e75a080, sk ffff88010323ac00
...
[69713.819021] [8909] hci_dev_hold: hci0 orig refcnt 10
[69713.819025] [8909] l2cap_connect_cfm: hcon ffff88021f65a000 bdaddr 00:1b:dc:06:06:22 status 0
[69713.819028] [8909] hci_chan_create: hci0 hcon ffff88021f65a000
[69713.819031] [8909] l2cap_conn_add: hcon ffff88021f65a000 conn ffff880221005c00 hchan ffff88020d60b1c0
[69713.819034] [8909] l2cap_conn_ready: conn ffff880221005c00
[69713.819036] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.819037] [8909] smp_conn_security: conn ffff880221005c00 hcon ffff88021f65a000 level 0x02
[69713.819039] [8909] smp_chan_create:
[69713.819041] [8909] hci_conn_hold: hcon ffff88021f65a000 orig refcnt 1
[69713.819043] [8909] smp_send_cmd: code 0x01
[69713.819045] [8909] hci_send_acl: hci0 chan ffff88020d60b1c0 flags 0x0000
[69713.819046] [5949] hci_sock_recvmsg: sock ffff8800941a9900, sk ffff88012bf4e800
[69713.819049] [8909] hci_queue_acl: hci0 nonfrag skb ffff88005157c100 len 15
[69713.819055] [5949] hci_sock_recvmsg: sock ffff8800941a9900, sk ffff88012bf4e800
[69713.819057] [8909] l2cap_le_conn_ready:
[69713.819064] [8909] l2cap_chan_create: chan ffff88005ede2c00
[69713.819066] [8909] l2cap_chan_hold: chan ffff88005ede2c00 orig refcnt 1
[69713.819069] [8909] l2cap_sock_init: sk ffff88005ede5800
[69713.819072] [8909] bt_accept_enqueue: parent ffff880160356000, sk ffff88005ede5800
[69713.819074] [8909] __l2cap_chan_add: conn ffff880221005c00, psm 0x00, dcid 0x0004
[69713.819076] [8909] l2cap_chan_hold: chan ffff88005ede2c00 orig refcnt 2
[69713.819078] [8909] hci_conn_hold: hcon ffff88021f65a000 orig refcnt 2
[69713.819080] [8909] smp_conn_security: conn ffff880221005c00 hcon ffff88021f65a000 level 0x01
[69713.819082] [8909] l2cap_sock_ready_cb: sk ffff88005ede5800, parent ffff880160356000
[69713.819086] [8909] le_pairing_complete_cb: status 0
[69713.819091] [8909] hci_tx_work: hci0 acl 10 sco 8 le 0
[69713.819093] [8909] hci_sched_acl: hci0
[69713.819094] [8909] hci_sched_sco: hci0
[69713.819096] [8909] hci_sched_esco: hci0
[69713.819098] [8909] hci_sched_le: hci0
[69713.819099] [8909] hci_chan_sent: hci0
[69713.819101] [8909] hci_chan_sent: chan ffff88020d60b1c0 quote 10
[69713.819104] [8909] hci_sched_le: chan ffff88020d60b1c0 skb ffff88005157c100 len 15 priority 7
[69713.819106] [8909] hci_send_frame: hci0 type 2 len 15
[69713.819108] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 15
[69713.819119] [8909] hci_chan_sent: hci0
[69713.819121] [8909] hci_prio_recalculate: hci0
[69713.819123] [8909] process_pending_rx:
[69713.819226] [6450] hci_sock_recvmsg: sock ffff88005e758780, sk ffff88010323d400
...
[69713.822022] [6450] l2cap_sock_accept: sk ffff880160356000 timeo 0
[69713.822024] [6450] bt_accept_dequeue: parent ffff880160356000
[69713.822026] [6450] bt_accept_unlink: sk ffff88005ede5800 state 1
[69713.822028] [6450] l2cap_sock_accept: new socket ffff88005ede5800
[69713.822368] [6450] l2cap_sock_getname: sock ffff8800941ab700, sk ffff88005ede5800
[69713.822375] [6450] l2cap_sock_getsockopt: sk ffff88005ede5800
[69713.822383] [6450] l2cap_sock_getname: sock ffff8800941ab700, sk ffff88005ede5800
[69713.822414] [6450] bt_sock_poll: sock ffff8800941ab700, sk ffff88005ede5800
...
[69713.823255] [6450] l2cap_sock_getname: sock ffff8800941ab700, sk ffff88005ede5800
[69713.823259] [6450] l2cap_sock_getsockopt: sk ffff88005ede5800
[69713.824322] [6450] l2cap_sock_getname: sock ffff8800941ab700, sk ffff88005ede5800
[69713.824330] [6450] l2cap_sock_getsockopt: sk ffff88005ede5800
[69713.825029] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800
...
[69713.825187] [6450] l2cap_sock_sendmsg: sock ffff8800941ab700, sk ffff88005ede5800
[69713.825189] [6450] bt_sock_wait_ready: sk ffff88005ede5800
[69713.825192] [6450] l2cap_create_basic_pdu: chan ffff88005ede2c00 len 3
[69713.825196] [6450] l2cap_do_send: chan ffff88005ede2c00, skb ffff880160b0b500 len 7 priority 0
[69713.825199] [6450] hci_send_acl: hci0 chan ffff88020d60b1c0 flags 0x0000
[69713.825201] [6450] hci_queue_acl: hci0 nonfrag skb ffff880160b0b500 len 11
[69713.825210] [8909] hci_tx_work: hci0 acl 9 sco 8 le 0
[69713.825213] [8909] hci_sched_acl: hci0
[69713.825214] [8909] hci_sched_sco: hci0
[69713.825216] [8909] hci_sched_esco: hci0
[69713.825217] [8909] hci_sched_le: hci0
[69713.825219] [8909] hci_chan_sent: hci0
[69713.825221] [8909] hci_chan_sent: chan ffff88020d60b1c0 quote 9
[69713.825223] [8909] hci_sched_le: chan ffff88020d60b1c0 skb ffff880160b0b500 len 11 priority 0
[69713.825225] [8909] hci_send_frame: hci0 type 2 len 11
[69713.825227] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 11
[69713.825242] [8909] hci_chan_sent: hci0
[69713.825253] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.825253] [8909] hci_prio_recalculate: hci0
[69713.825292] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.825768] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800
...
[69713.866902] [8909] hci_rx_work: hci0
[69713.866921] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 7
[69713.866928] [8909] hci_rx_work: hci0 Event packet
[69713.866931] [8909] hci_num_comp_pkts_evt: hci0 num_hndl 1
[69713.866937] [8909] hci_tx_work: hci0 acl 9 sco 8 le 0
[69713.866939] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.866940] [8909] hci_sched_acl: hci0
...
[69713.866944] [8909] hci_sched_le: hci0
[69713.866953] [8909] hci_chan_sent: hci0
[69713.866997] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.867840] [28074] hci_rx_work: hci0
[69713.867844] [28074] hci_send_to_monitor: hdev ffff88021f0c7000 len 7
[69713.867850] [28074] hci_rx_work: hci0 Event packet
[69713.867853] [28074] hci_num_comp_pkts_evt: hci0 num_hndl 1
[69713.867857] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69713.867858] [28074] hci_tx_work: hci0 acl 10 sco 8 le 0
[69713.867860] [28074] hci_sched_acl: hci0
[69713.867861] [28074] hci_sched_sco: hci0
[69713.867862] [28074] hci_sched_esco: hci0
[69713.867863] [28074] hci_sched_le: hci0
[69713.867865] [28074] hci_chan_sent: hci0
[69713.867888] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69714.145661] [8909] hci_rx_work: hci0
[69714.145666] [8909] hci_send_to_monitor: hdev ffff88021f0c7000 len 10
[69714.145676] [8909] hci_rx_work: hci0 ACL data packet
[69714.145679] [8909] hci_acldata_packet: hci0 len 6 handle 0x002d flags 0x0002
[69714.145681] [8909] hci_conn_enter_active_mode: hcon ffff88021f65a000 mode 0
[69714.145683] [8909] l2cap_recv_acldata: conn ffff880221005c00 len 6 flags 0x2
[69714.145693] [8909] l2cap_recv_frame: len 2, cid 0x0006
[69714.145696] [8909] hci_send_to_control: len 14
[69714.145710] [8909] smp_chan_destroy:
[69714.145713] [8909] pairing_complete: status 3
[69714.145714] [8909] cmd_complete: sock ffff88010323ac00
[69714.145717] [8909] hci_conn_drop: hcon ffff88021f65a000 orig refcnt 3
[69714.145719] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69714.145720] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800
[69714.145722] [6515] hci_sock_recvmsg: sock ffff88005e75a080, sk ffff88010323ac00
[69714.145724] [6450] bt_sock_poll: sock ffff8801db6b4f00, sk ffff880160351c00
...
[69714.145735] [6515] hci_sock_recvmsg: sock ffff88005e75a080, sk ffff88010323ac00
[69714.145737] [8909] hci_conn_drop: hcon ffff88021f65a000 orig refcnt 2
[69714.145739] [8909] l2cap_conn_del: hcon ffff88021f65a000 conn ffff880221005c00, err 13
[69714.145740] [6450] bt_sock_poll: sock ffff8801db6b5400, sk ffff88021e775000
[69714.145743] [6450] bt_sock_poll: sock ffff8801db6b5e00, sk ffff880160356000
[69714.145744] [8909] l2cap_chan_hold: chan ffff88005ede2c00 orig refcnt 3
[69714.145746] [6450] bt_sock_poll: sock ffff8800941ab700, sk ffff88005ede5800
[69714.145748] [8909] l2cap_chan_del: chan ffff88005ede2c00, conn ffff880221005c00, err 13
[69714.145749] [8909] l2cap_chan_put: chan ffff88005ede2c00 orig refcnt 4
[69714.145751] [8909] hci_conn_drop: hcon ffff88021f65a000 orig refcnt 1
[69714.145754] [6450] bt_sock_poll: sock ffff8800941ab700, sk ffff88005ede5800
[69714.145756] [8909] l2cap_chan_put: chan ffff88005ede2c00 orig refcnt 3
[69714.145759] [8909] hci_chan_del: hci0 hcon ffff88021f65a000 chan ffff88020d60b1c0
[69714.145766] [5949] hci_sock_recvmsg: sock ffff8800941a9680, sk ffff88012bf4d000
[69714.145787] [6515] hci_sock_release: sock ffff88005e75a080 sk ffff88010323ac00
[69714.146002] [6450] hci_sock_recvmsg: sock ffff88005e758780, sk ffff88010323d400
[69714.150795] [6450] l2cap_sock_release: sock ffff8800941ab700, sk ffff88005ede5800
[69714.150799] [6450] l2cap_sock_shutdown: sock ffff8800941ab700, sk ffff88005ede5800
[69714.150802] [6450] l2cap_chan_close: chan ffff88005ede2c00 state BT_CLOSED
[69714.150805] [6450] l2cap_sock_kill: sk ffff88005ede5800 state BT_CLOSED
[69714.150806] [6450] l2cap_chan_put: chan ffff88005ede2c00 orig refcnt 2
[69714.150808] [6450] l2cap_sock_destruct: sk ffff88005ede5800
[69714.150809] [6450] l2cap_chan_put: chan ffff88005ede2c00 orig refcnt 1
[69714.150811] [6450] l2cap_chan_destroy: chan ffff88005ede2c00
[69714.150970] [6450] bt_sock_poll: sock ffff88005e758500, sk ffff88010323b800
...
[69714.151991] [8909] hci_conn_drop: hcon ffff88021f65a000 orig refcnt 0
[69716.150339] [8909] hci_conn_timeout: hcon ffff88021f65a000 state BT_CONNECTED, refcnt -1
Signed-off-by: Lukasz Rymanowski <lukasz.rymanowski@tieto.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| e694788d73efe139b24f78b036deb97fe57fa8cb |
|
10-Jun-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix check for connection encryption
The conn->link_key variable tracks the type of link key in use. It is
set whenever we respond to a link key request as well as when we get a
link key notification event.
These two events do not however always guarantee that encryption is
enabled: getting a link key request and responding to it may only mean
that the remote side has requested authentication but not encryption. On
the other hand, the encrypt change event is a certain guarantee that
encryption is enabled. The real encryption state is already tracked in
the conn->link_mode variable through the HCI_LM_ENCRYPT bit.
This patch fixes a check for encryption in the hci_conn_auth function to
use the proper conn->link_mode value and thereby eliminates the chance
of a false positive result.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
|
| b62b65055bcc5372d5c3f4103629176cb8db3678 |
|
04-Jun-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix incorrectly overriding conn->src_type
The src_type member of struct hci_conn should always reflect the address
type of the src_member. It should never be overridden. There is already
code in place in the command status handler of HCI_LE_Create_Connection
to copy the right initiator address into conn->init_addr_type.
Without this patch, if privacy is enabled, we will send the wrong
address type in the SMP identity address information PDU (it'll e.g.
contain our public address but a random address type).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
|
| 4bc58f51e156227d139668199ffe5df2ccb2f3c2 |
|
20-May-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Make SMP context private to smp.c
There are no users of the smp_chan struct outside of smp.c so move it
away from smp.h. The addition of the l2cap.h include to hci_core.c,
hci_conn.c and mgmt.c is something that should have been there already
previously to avoid warnings of undeclared struct l2cap_conn, but the
compiler warning was apparently shadowed away by the mention of
l2cap_conn in the struct smp_chan definition.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| d0455ed996df84fd2670a655fe13ab72f8264765 |
|
14-May-2014 |
Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> |
Bluetooth: Store max TX power level for connection
This patch adds support to store local maximum TX power level for
connection when reply for HCI_Read_Transmit_Power_Level is received.
Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 5a134faeef82b46ff4ad244d11d8c6be41679834 |
|
09-May-2014 |
Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> |
Bluetooth: Store TX power level for connection
This patch adds support to store local TX power level for connection
when reply for HCI_Read_Transmit_Power_Level is received.
Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 09da1f3463eb81d59685df723b1c5950b7570340 |
|
11-Apr-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix redundant encryption request for reauthentication
When we're performing reauthentication (in order to elevate the
security level from an unauthenticated key to an authenticated one) we
do not need to issue any encryption command once authentication
completes. Since the trigger for the encryption HCI command is the
ENCRYPT_PEND flag this flag should not be set in this scenario.
Instead, the REAUTH_PEND flag takes care of all necessary steps for
reauthentication.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
|
| 3c857757ef6e5a4e472bd3e5c934709c2eb482af |
|
25-Mar-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Add directed advertising support through connect()
When we're in peripheral mode (HCI_ADVERTISING flag is set) the most
natural mapping of connect() is to perform directed advertising to the
peer device.
This patch does the necessary changes to enable directed advertising and
keeps the hci_conn state as BT_CONNECT in a similar way as is done for
central or BR/EDR connection initiation.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 9c84d1da974ee8b54fa49ae369648a0247b7cd6f |
|
24-Mar-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Move local identity address setting to a central place
Any time hci_conn_add is used for an LE connection we need to ensure
that the local identity address is correctly described in the src and
src_type variables. This patch moves setting these values directly into
hci_conn_add so that callers don't have to duplicate the effort
themselves.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 40b552aa5a0bfa785bc7ddb5c2d7965b1e0bb08d |
|
19-Mar-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Enforce strict Secure Connections Only mode security
In Secure Connections Only mode, it is required that Secure Connections
is used for pairing and that the link key is encrypted with AES-CCM using
a P-256 authenticated combination key. If this is not the case, then new
connection shall be refused or existing connections shall be dropped.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| dcf4adbfdc7ad14ca50c1133f93f998c78493c2d |
|
12-Mar-2014 |
Joe Perches <joe@perches.com> |
Bluetooth: Convert uses of __constant_<foo> to <foo>
The use of __constant_<foo> has been unnecessary for quite awhile now.
Make these uses consistent with the rest of the kernel.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 81ad6fd9698f659dbabdc6cd3e1667a98eb2be3b |
|
28-Feb-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Remove unnecessary stop_scan_complete function
The stop_scan_complete function was used as an intermediate step before
doing the actual connection creation. Since we're using hci_request
there's no reason to have this extra function around, i.e. we can simply
put both HCI commands into the same request.
The single task that the intermediate function had, i.e. indicating
discovery as stopped is now taken care of by a new
HCI_LE_SCAN_INTERRUPTED flag which allows us to do the discovery state
update when the stop scan command completes.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 317ac8cb3f9fb58b9ec5764b766a449004ab2a62 |
|
28-Feb-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix trying to disable scanning twice
The discovery process has a timer for disabling scanning, however
scanning might be disabled through other means too like the auto-connect
process. We should therefore ensure that the timer is never active
after sending a HCI command to disable scanning.
There was some existing code in stop_scan_complete trying to avoid the
timer when a connect request interrupts a discovery procedure, but the
other way around was not covered. This patch covers both scenarios by
canceling the timer as soon as we get a successful command complete for
the disabling HCI command.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 9489eca4ab2fd5d9bbf3bab992168cc8107fc3e9 |
|
28-Feb-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Add timeout for LE connection attempts
LE connection attempts do not have a controller side timeout in the same
way as BR/EDR has (in form of the page timeout). Since we always do
scanning before initiating connections the attempts are always expected
to succeed in some reasonable time.
This patch adds a timer which forces a cancellation of the connection
attempt within 20 seconds if it has not been successful by then. This
way we e.g. ensure that mgmt_pair_device times out eventually and gives
an error response.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| b46e00308929cc0317a021a7ac050790f023b1ca |
|
27-Feb-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix updating connection state to BT_CONNECT too early
We shouldn't update the hci_conn state to BT_CONNECT until the moment
that we're ready to send the initiating HCI command for it. If the
connection has the BT_CONNECT state too early the code responsible for
updating the local random address may incorrectly think there's a
pending connection in progress and refuse to update the address.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| fe39c7b2dacf7fd4dcddc26704d01315ab92b7cb |
|
28-Feb-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Use __le64 type for LE random numbers
The random numbers in Bluetooth Low Energy are 64-bit numbers and should
also be little endian since the HCI specification is little endian.
Change the whole Low Energy pairing to use __le64 instead of a byte
array.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| a4790dbd43d1617b09d57e96494fde5a4b01980a |
|
27-Feb-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Introduce LE auto connection infrastructure
This patch introduces the LE auto connection infrastructure which
will be used to implement the LE auto connection options.
In summary, the auto connection mechanism works as follows: Once the
first pending LE connection is created, the background scanning is
started. When the target device is found in range, the kernel
autonomously starts the connection attempt. If connection is
established successfully, that pending LE connection is deleted and
the background is stopped.
To achieve that, this patch introduces the hci_update_background_scan()
which controls the background scanning state. This function starts or
stops the background scanning based on the hdev->pend_le_conns list. If
there is no pending LE connection, the background scanning is stopped.
Otherwise, we start the background scanning.
Then, every time a pending LE connection is added we call hci_update_
background_scan() so the background scanning is started (in case it is
not already running). Likewise, every time a pending LE connection is
deleted we call hci_update_background_scan() so the background scanning
is stopped (in case this was the last pending LE connection) or it is
started again (in case we have more pending LE connections). Finally,
we also call hci_update_background_scan() in hci_le_conn_failed() so
the background scan is restarted in case the connection establishment
fails. This way the background scanning keeps running until all pending
LE connection are established.
At this point, resolvable addresses are not support by this
infrastructure. The proper support is added in upcoming patches.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 6f77d8c757523f675679d845ff0e15d3276a168a |
|
27-Feb-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Move address type conversion to outside hci_connect_le
This patch moves address type conversion (L2CAP address type to HCI
address type) to outside hci_connect_le. This way, we avoid back and
forth address type conversion in a comming patch.
So hci_connect_le() now expects 'dst_type' parameter in HCI address
type convention.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 04a6c5898e8cbb46313b7d425001b701f0fa4e3d |
|
27-Feb-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Refactor HCI connection code
hci_connect() is a very simple and useless wrapper of hci_connect_acl
and hci_connect_le functions. Addtionally, all places where hci_connect
is called the link type value is passed explicitly. This way, we can
safely delete hci_connect, declare hci_connect_acl and hci_connect_le
in hci_core.h and call them directly.
No functionality is changed by this patch.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| c99ed8343cdf84279f4d1937d25a3b644a14ed0d |
|
27-Feb-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Remove unused function
This patch removes hci_create_le_conn() since it is not used anymore.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 2acf3d9066b36e1b05db42bfe43152eee07a5e9e |
|
27-Feb-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Stop scanning on LE connection
Some LE controllers don't support scanning and creating a connection
at the same time. So we should always stop scanning in order to
establish the connection.
Since we may prematurely stop the discovery procedure in favor of
the connection establishment, we should also cancel hdev->le_scan_
disable delayed work and set the discovery state to DISCOVERY_STOPPED.
This change does a small improvement since it is not mandatory the
user stops scanning before connecting anymore. Moreover, this change
is required by upcoming LE auto connection mechanism in order to work
properly with controllers that don't support background scanning and
connection establishment at the same time.
In future, we might want to do a small optimization by checking if
controller is able to scan and connect at the same time. For now,
we want the simplest approach so we always stop scanning (even if
the controller is able to carry out both operations).
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 06c053fb54c10be49ef30fc9b6b01e42cc9a1b61 |
|
27-Feb-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Declare le_conn_failed in hci_core.h
This patch adds the "hci_" prefix to le_conn_failed() helper and
declares it in hci_core.h so it can be reused in hci_event.c.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 94b1fc92cd7cf550460ffd4bcc08c2707564aa49 |
|
24-Feb-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Use unresolvable private address for active scanning
When running active scanning during LE discovery, do not reveal the own
identity to the peer devices. In case LE privacy has been enabled, then
a resolvable private address is used. If the LE privacy option is off,
then use an unresolvable private address.
The public address or static random address is never used in active
scanning anymore. This ensures that scan request are send using a
random address.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| e26b1ffa11bb1e0afa194823623ee64b7e143993 |
|
23-Feb-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix setting correct src_type when connecting LE
This patch ensures that conn->src_type contains the same address type as
is used for initiating the connection while the connection attempt is in
progress. Once connected this value will be overwritten with the
identity address type.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 85030be4c5ce39e709b2cb5d4f8ee8779af8e50b |
|
23-Feb-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Use hci_update_random_address() when connecting LE
When we initiate LE connections we need to update the local random
address if necessary. This patch updates the LE connection creation
mechanism to use the new hci_update_random_address() function to set the
own_address_type parameter and to update the local random address if
necessary.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| d66c295031aec712e179d21de66602d631390f34 |
|
19-Feb-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Use same LE min/max connection event length during update
During LE connection establishment the value 0x0000 is used for min/max
connection event length. So use the same value when the peripheral is
requesting an update of the the connection paramters.
For some reason the value 0x0001 got used in the connection update and
0x0000 in the connection creation. Using the same value for both just
makes sense.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| edb4b46651c87f1579154298c41f9c1a753565a3 |
|
19-Feb-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Fix wrong identity address during connection failures
When the connection attempt fails, the address information are not
provided in the HCI_LE_Connection_Complete event. So use the original
information from the connection to reconstruct the identity address.
This is important when a connection attempt has been made using the
identity address, but the cached resolvable random address has changed
in the meantime. The failure event needs to use the identity address
and not the resolvable random address.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 1ebfcc1f5884509925522ab76c17db9befe0aac9 |
|
18-Feb-2014 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Look up RPA for connection requests with Identity Address
We need to check whether there's a matching IRK and RPA when we're
requested to connect to a remote LE device based on its Identity
Address. This patch updates the hci_connect_le function to do an extra
call to hci_find_irk_by_addr and uses the RPA if it's cached. This is
particularly important once we start exposing the Identity Address to
user space instead of the RPA in events such as Device Connected and
Device Found.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 4292f1f3370193fd3f2e4f849211fd9596ce832f |
|
03-Feb-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Use connection parameters if any
This patch changes hci_connect_le() so it uses the connection
parameters specified for the certain device. If no parameters
were configured, we use the default values.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 9cb2e030e6a0787f5c216702e6e78dd85ffe04c4 |
|
01-Feb-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Include security level 4 in connections check
This check is only used for RFCOMM connections and most likely no
RFCOMM based profile will require security level 4 secure connection
security policy. In case it ever does make sure that seucrity level 4
is treated as sufficient security level.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 9bb3c01fdb2201d405dfff8950145640b2355ec4 |
|
30-Jan-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Introduce le_conn_failed() helper
This patch moves connection attempt failure code to its own function
so it can be reused in the next patch.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 1e406eefbe41467c00973939c2b61b37bf0e1323 |
|
30-Jan-2014 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Save connection interval parameters in hci_conn
This patch creates two new fields in struct hci_conn to save the
minimum and maximum connection interval values used to establish
the connection this object represents.
This change is required in order to know what parameters the
connection is currently using.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 7b5a9241b780ea2f77e71647bc0d3c9708c18ef1 |
|
16-Jan-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Introduce requirements for security level 4
The security level 4 is a new strong security requirement that is based
around 128-bit equivalent strength for link and encryption keys required
using FIPS approved algorithms. Which means that E0, SAFER+ and P-192
are not allowed. Only connections created with P-256 resulting from
using Secure Connections support are allowed.
This security level needs to be enforced when Secure Connection Only
mode is enabled for a controller or a service requires FIPS compliant
strong security. Currently it is not possible to enable either of
these two cases. This patch just puts in the foundation for being
able to handle security level 4 in the future.
It should be noted that devices or services with security level 4
requirement can only communicate using Bluetooth 4.1 controllers
with support for Secure Connections. There is no backward compatibilty
if used with older hardware.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 66138ce8e556a8ddd13baf035fb3a8d0d6dd4bb5 |
|
10-Jan-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Add support for handling P-256 derived link keys
Before being able to enable Secure Connections support, the core needs
to know on how to handle P-256 derived link keys. The difference between
authenticated and unauthenticated P-256 derived link keys is the same as
its P-192 counter parts.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 11015c7903c74350402f8753339c48bee0186e90 |
|
10-Jan-2014 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Add definitions for new link key types
With the introduction of Secure Connections, the list of link key types
got extended by P-256 versions of authenticated and unauthenticated
link keys.
To avoid any confusion the previous authenticated and unauthenticated
link key types got ammended with a P912 postfix. And the two new keys
have a P256 postfix now. Existing code using the previous definitions
has been adjusted.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 4e70c7e71c5f9cf11013628ab5a0ced449b1c7b2 |
|
19-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Expose debugfs settings for LE connection interval
For testing purposes expose the default LE connection interval values
via debugfs.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 79830f66e3cbd224bcf697b032dce9828b5a3c9e |
|
19-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Select the own address type during initial setup phase
The own address type is based on the fact if the controller has
a public address or not. This means that this detail can be just
configured once during setup phase.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| a74a84f696537f38fa994c1b95a0dca9ae386865 |
|
16-Oct-2013 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Convert idle timer to use delayed work
There is no need to use a timer since the entire Bluetooth subsystem
runs using workqueues these days.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 7bc18d9d3d7ffbc09dabb201933a063583a39027 |
|
16-Oct-2013 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Convert auto accept timer to use delayed work
Since the entire Bluetooth subsystem runs in workqueues these days there
is no need to use a timer for deferring work.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 662e8820f38dcc458e0d4769194db5ed3469224f |
|
13-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Store source address of HCI connections
The source addressed was based on the public address of the HCI device,
but with LE connections this not always the case. For example single
mode LE-only controllers would use a static random address. And this
address is configured by userspace.
To not complicate the lookup of what kind of address is in use, store
the correct source address for each HCI connection.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| e7c4096e16f0e362c6cf902baab0de37ebfc1266 |
|
13-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Store the source address type of LE connections
When establishing LE connections, it is possible to use a public
address (if available) or a random address. The type of address
is only known when creating connections, so make sure it is
stored in hci_conn structure.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 79d95a19a445f5758571b3342064f2c1e40b6c5f |
|
13-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Remove pointless bdaddr_to_le() helper function
The bdaddr_to_le() function tries to convert the internal address
type to one that matches the HCI address type for LE. It does not
handle any address types not used by LE and in the end just make
the code a lot harder to read.
So instead of just hiding behind a magic function, just convert
the internal address type where it needs to be converted. And it
turns out that these are only two cases anyway. One when creating
new LE connections and the other when loading the long term keys.
In both cases this makes it more clear on what it going on.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| bef64738e3fb87eabc6fbeededad0c44ea173384 |
|
11-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Make LE scan interval and window a controller option
The scan interval and window for LE passive scanning and connection
establishment should be configurable on a per controller basis. So
introduce a setting that later on will allow modifying it.
This setting does not affect LE active scanning during device
discovery phase. As long as that phase uses interleaved discovery,
it will continuously scan.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| ac4b7236610cef99821f40f44a74030b85d85270 |
|
10-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Move smp.h header file into net/bluetooth/
The smp.h header file is only used internally by the bluetooth.ko
module and is not a public API. So make it local to the core
Bluetooth module.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 7024728ee534d739380dc4fd31f020cfc6e86c28 |
|
10-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Move a2mp.h header file into net/bluetooth/
The a2mp.h header file is only used internally by the bluetooth.ko
module and is not a public API. So make it local to the core
Bluetooth module.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 620ad5219c0f0aa43731b2fd8fd9efac78c10deb |
|
08-Oct-2013 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Refactor hci_connect_le
This patch does some code refactoring in hci_connect_le() by moving
the exception code into if statements and letting the main flow in
first level of function scope. It also adds extra comments to improve
the code readability.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 1d399ae5c74619c841fa13834c4f79506aaf6957 |
|
08-Oct-2013 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Use HCI request for LE connection
This patch introduces a new helper, which uses the HCI request
framework, for creating LE connectons. All the handling is now
done by this function so we can remove the hci_cs_le_create_conn()
event handler.
This patch also removes the old hci_le_create_connection() since
it is not used anymore.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| c25dfc610b983f74f05b3c12d9ad4ff4af6cd858 |
|
06-Oct-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Use random address if public address is not available
For single mode LE-only controllers, it is possible that they come
without a public address. If a public address is not available,
then use the random address for connection establishment and
scanning.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| f3d3444a4d7f76e79841c59c78105a45295cc4b0 |
|
05-Oct-2013 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Rename HCI_LE_PERIPHERAL to HCI_ADVERTISING
This flag is used to indicate whether we want to have advertising
enabled or not, so give it a more suitable name.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 46a190cbd3d8992a017664367e9227dcd357ce53 |
|
03-Oct-2013 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Initialize hci_conn fields in hci_connect_le
This patch moves some hci_conn fields initialization from hci_le_
create_connection() to hci_connect_le(). It makes more sense to
initialize these fields within the function that creates the hci_
conn object.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| f1e5d54743b99cbbea0e0cfb2b3f8053f045b3d7 |
|
03-Oct-2013 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Rename hci_conn variable in hci_connect_le()
This patch simply rename the hci_conn variable "le" to "conn"
since it is a better name.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 56f8790102f48a4959a729ecdccff332591014e1 |
|
02-Oct-2013 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Introduce a new HCI_BREDR_ENABLED flag
To allow treating dual-mode (BR/EDR/LE) controllers as single-mode ones
(LE-only) we want to introduce a new HCI_BREDR_ENABLED flag to track
whether BR/EDR is enabled or not (previously we simply looked at the
feature bit with lmp_bredr_enabled).
This patch add the new flag and updates the relevant places to test
against it instead of using lmp_bredr_enabled. The flag is by default
enabled when registering an adapter and only cleared if necessary once
the local features have been read during the HCI init procedure.
We cannot completely block BR/EDR usage in case user space uses raw HCI
sockets but the patch tries to block this in places where possible, such
as the various BR/EDR specific ioctls.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| af750e942ea138553ee5693210c2f918448f58dc |
|
04-Sep-2013 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Disable upper layer connections when user channel is active
When the device has the user channel flag set, it means it is driven by
an user application. In that case do not allow any connections from
L2CAP or SCO sockets.
This is the same situation as when the device has the raw flag set and
it will then return EHOSTUNREACH.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Acked-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 2dea632f9acad076370fe871d4ccc93868621403 |
|
19-Aug-2013 |
Frédéric Dalleau <frederic.dalleau@linux.intel.com> |
Bluetooth: Add SCO connection fallback
When initiating a transparent eSCO connection, make use of T2 settings
at first try. T2 is the recommended settings from HFP 1.6 WideBand
Speech. Upon connection failure, try T1 settings.
When CVSD is requested and eSCO is supported, try to establish eSCO
connection using S3 settings. If it fails, fallback in sequence to S2,
S1, D1, D0 settings.
To know which setting should be used, conn->attempt is used. It
indicates the currently ongoing SCO connection attempt and can be used
as the index for the fallback settings table.
These setting and the fallback order are described in Bluetooth HFP 1.6
specification p. 101.
Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 10c62ddc6f032c3a096401ca3ce7e5b2d5780859 |
|
19-Aug-2013 |
Frédéric Dalleau <frederic.dalleau@linux.intel.com> |
Bluetooth: Parameters for outgoing SCO connections
In order to establish a transparent SCO connection, the correct settings
must be specified in the Setup Synchronous Connection request. For that,
a setting field is added to ACL connection data to set up the desired
parameters. The patch also removes usage of hdev->voice_setting in CVSD
connection and makes use of T2 parameters for transparent data.
Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| e660ed6c70370dae0887e2b5224d8b6c1e138120 |
|
19-Aug-2013 |
Frédéric Dalleau <frederic.dalleau@linux.intel.com> |
Bluetooth: Use hci_connect_sco directly
hci_connect is a super function for connecting hci protocols. But the
voice_setting parameter (introduced in subsequent patches) is only
needed by SCO and security requirements are not needed for SCO channels.
Thus, it makes sense to have a separate function for SCO.
Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 8d12356f33f819ec0d064e233f7ca8e59eaa38ef |
|
06-Apr-2013 |
David Herrmann <dh.herrmann@gmail.com> |
Bluetooth: introduce hci_conn ref-counting
We currently do not allow using hci_conn from outside of HCI-core.
However, several other users could make great use of it. This includes
HIDP, rfcomm and all other sub-protocols that rely on an active
connection.
Hence, we now introduce hci_conn ref-counting. We currently never call
get_device(). put_device() is exclusively used in hci_conn_del_sysfs().
Hence, we currently never have a greater device-refcnt than 1.
Therefore, it is safe to move the put_device() call from
hci_conn_del_sysfs() to hci_conn_del() (it's the only caller). In fact,
this even fixes a "use-after-free" bug as we access hci_conn after calling
hci_conn_del_sysfs() in hci_conn_del().
From now on we can add references to hci_conn objects in other layers
(like l2cap_sock, HIDP, rfcomm, ...) and grab a reference via
hci_conn_get(). This does _not_ guarantee, that the connection is still
alive. But, this isn't what we want. We can simply lock the hci_conn
device and use "device_is_registered(hci_conn->dev)" to test that.
However, this is hardly necessary as outside users should never rely on
the HCI connection to be alive, anyway. Instead, they should solely rely
on the device-object to be available.
But if sub-devices want the hci_conn object as sysfs parent, they need to
be notified when the connection drops. This will be introduced in later
patches with l2cap_users.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| fc225c3f5d1b6aa6f99c5c300af4605e4923ce79 |
|
06-Apr-2013 |
David Herrmann <dh.herrmann@gmail.com> |
Bluetooth: remove unneeded hci_conn_hold/put_device()
hci_conn_hold/put_device() is used to control when hci_conn->dev is no
longer needed and can be deleted from the system. Lets first look how they
are currently used throughout the code (excluding HIDP!).
All code that uses hci_conn_hold_device() looks like this:
...
hci_conn_hold_device();
hci_conn_add_sysfs();
...
On the other side, hci_conn_put_device() is exclusively used in
hci_conn_del().
So, considering that hci_conn_del() must not be called twice (which would
fail horribly), we know that hci_conn_put_device() is only called _once_
(which is in hci_conn_del()).
On the other hand, hci_conn_add_sysfs() must not be called twice, either
(it would call device_add twice, which breaks the device, see
drivers/base/core.c). So we know that hci_conn_hold_device() is also
called only once (it's only called directly before hci_conn_add_sysfs()).
So hold and put are known to be called only once. That means we can safely
remove them and directly call hci_conn_del_sysfs() in hci_conn_del().
But there is one issue left: HIDP also uses hci_conn_hold/put_device().
However, this case can be ignored and simply removed as it is totally
broken. The issue is, the only thing HIDP delays with
hci_conn_hold_device() is the removal of the hci_conn->dev from sysfs.
But, the hci_conn device has no mechanism to get notified when its own
parent (hci_dev) gets removed from sysfs. hci_dev_hold/put() does _not_
control when it is removed but only when the device object is created
and destroyed.
And hci_dev calls hci_conn_flush_*() when it removes itself from sysfs,
which itself causes hci_conn_del() to be called, but it does _not_ cause
hci_conn_del_sysfs() to be called, which is wrong.
Hence, we fix it to call hci_conn_del_sysfs() in hci_conn_del(). This
guarantees that a hci_conn object is removed from sysfs _before_ its
parent hci_dev is removed.
The changes to HIDP look scary, wrong and broken. However, if you look at
the HIDP session management, you will notice they're already broken in the
exact _same_ way (ever tried "unplugging" HIDP devices? Breaks _all_ the
time).
So this patch only makes HIDP look _scary_ and _obviously broken_. It does
not break HIDP itself, it already is!
See later patches in this series which fix HIDP to use proper
session-management.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 93796fa6f21411dab2ce7ba4fd7fd4d4ed4aca2e |
|
11-Apr-2013 |
Claudio Takahasi <claudio.takahasi@openbossa.org> |
Bluetooth: Reject SCO when hci connection timeouts
This patch sends Reject Synchronous Connection Request Command when
hci_conn_timeout is triggered, and the SCO connection is in BT_CONNECT2
state. It prevents inconsistency if the remote host doesn't implement
properly the timeout for the connection request, and it removes the
connection reference left when the socket is closed for incoming SCO
connections.
[ 2650.129080] sco_sock_release: sock ffff8801ca417400, sk ffff88020c408800
[ 2650.129092] sco_sock_clear_timer: sock ffff88020c408800 state 6
[ 2650.129101] __sco_sock_close: sk ffff88020c408800 state 6 socket
ffff8801ca417400
[ 2650.129108] sco_chan_del: sk ffff88020c408800, conn ffff8801c650ea20,
err 104
[ 2650.129114] hci_conn_put: hcon ffff88020c40a800 orig refcnt 1
[ 2650.129128] sco_sock_kill: sk ffff88020c408800 state 9
[ 2650.129135] sco_sock_destruct: sk ffff88020c408800
[ 2650.138468] hci_conn_timeout: hcon ffff88020c40a800 state BT_CONNECT2
Signed-off-by: Claudio Takahasi <claudio.takahasi@openbossa.org>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 76a68ba0ae097be72dfa8f918b3139130da769a4 |
|
06-Apr-2013 |
David Herrmann <dh.herrmann@gmail.com> |
Bluetooth: rename hci_conn_put to hci_conn_drop
We use _get() and _put() for device ref-counting in the kernel. However,
hci_conn_put() is _not_ used for ref-counting, hence, rename it to
hci_conn_drop() so we can later fix ref-counting and introduce
hci_conn_put().
hci_conn_hold() and hci_conn_put() are currently used to manage how long a
connection should be held alive. When the last user drops the connection,
we spawn a delayed work that performs the disconnect. Obviously, this has
nothing to do with ref-counting for the _object_ but rather for the
keep-alive of the connection.
But we really _need_ proper ref-counting for the _object_ to allow
connection-users like rfcomm-tty, HIDP or others.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| bed71748346ae0807c7f7a2913965508dbd61403 |
|
30-Jan-2013 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Rename hci_acl_disconn
As hci_acl_disconn function basically sends the HCI Disconnect Command
and it is used to disconnect ACL, SCO and LE links, renaming it to
hci_disconnect is more suitable.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 4c02e2d444595200d0b18b889994aac3611cd288 |
|
30-Jan-2013 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Fix hci_conn timeout routine
If occurs a LE or SCO hci_conn timeout and the connection is already
established (BT_CONNECTED state), the connection is not terminated as
expected. This bug can be reproduced using l2test or scotest tool.
Once the connection is established, kill l2test/scotest and the
connection won't be terminated.
This patch fixes hci_conn_disconnect helper so it is able to
terminate LE and SCO connections, as well as ACL.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| e9b02748ffc043e8a36f7893bbf58bb886f0b7e4 |
|
25-Oct-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Add put(hcon) when deleting hchan
When refcnt reaches zero disconnect timeout will run and hci_conn
will be disconnected.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| f15504788d7b1613ef2ef0a673cfe250c16a6b0d |
|
24-Oct-2012 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Disallow LE scanning and connecting in peripheral role
When an adapter is in the LE peripheral role scanning for other devices
or initiating connections to them is not allowed. This patch makes sure
that such attempts will result in appropriate error returns.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 168df8e57e7c1afce3f86a86ae106f82ff7c18d8 |
|
24-Oct-2012 |
Mat Martineau <mathewm@codeaurora.org> |
Bluetooth: Add state to hci_chan
On an AMP controller, hci_chan maps to a logical link. When a channel
is being moved, the logical link may or may not be connected already.
The hci_chan->state is used to determine the existance of a useable
logical link so the link can be either used or requested.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Acked-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 42c4e53e7ac3d4069105e852d1ee24e6ee9e57b8 |
|
10-Oct-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: AMP: Add handle to hci_chan structure
hci_chan will be identified by handle used in logical link creation
process. This handle is used in AMP ACL-U packet handle field.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 53502d69be49e3dd5bc95ab0f2deeaea260bd617 |
|
10-Oct-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: AMP: Handle AMP_LINK timeout
When AMP_LINK timeouts execute HCI_OP_DISCONN_PHY_LINK as analog to
HCI_OP_DISCONNECT for ACL_LINK.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 6ed93dc6427d14cdfe0b272cc0a9ee4685ce9ad7 |
|
24-Sep-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Use %pMR in debug instead of batostr
Instead of old unsafe batostr function use %pMR print specifier
for printing Bluetooth addresses in debug and error statements.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 9472007c62ecc8f21daa2e1e252bf73b67e535fc |
|
06-Sep-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: trivial: Make hci_chan_del return void
Return code is not needed in hci_chan_del
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| d8343f125710fb596f7a88cd756679f14f4e77b9 |
|
24-Aug-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Fix sending a HCI Authorization Request over LE links
In the case that the link is already in the connected state and a
Pairing request arrives from the mgmt interface, hci_conn_security()
would be called but it was not considering LE links.
Reported-by: João Paulo Rechi Vita <jprvita@openbossa.org>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| f91c8468df97d0ac18132eb38283524a74317901 |
|
18-Aug-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Fix establishing ESCO links
Commit 4cd2d98340b4f03d5532c30fdaeb451b035429cb "Bluetooth: Simplify
the connection type handling" broke the creation of ESCO links.
This patch adds a type parameter to hci_connect_sco() so it creates
the connection of the right kind.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| e6dd548b9a3c7b3fcdd2fd97880abf7597e8334b |
|
28-Jul-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Add type information to the hci_connect() debug statement
Now that we have a "connect" function for each link type, we should be
able to indentify which function is going to be called.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 4cd2d98340b4f03d5532c30fdaeb451b035429cb |
|
28-Jul-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Simplify a the connection type handling
Now that we have separate ways of doing connections for each link type,
we can do better than an "if" statement to handle each link type.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| b7d839bfff78a01705f3d7b0acd5257dc7b067c9 |
|
28-Jul-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Refactor SCO connection into its own function
We can do the same that we did for the other link types, for SCO
connections. The only thing that's worth noting is that as SCO
links need an ACL link, this functions uses the function that adds
an ACL link.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| db4742756ae2a836618cd5acf599522573589149 |
|
29-Jul-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Refactor ACL connection into its own function
The hci_connect() function was starting to get too complicated to be
quickly understood. We can separate the creation of a new ACL
connection into its own function.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| d04aef4cccf203fdfd1716e9ba458060cbab0928 |
|
28-Jul-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Refactor LE connection into its own function
The code that handles LE connection is already quite separated from
the rest of the connection procedure, so we can easily put it into
its own.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 1aef866968223ddfd7268457b642a9233f0b8006 |
|
28-Jul-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Rename LE and ACL connection functions
These names were causing much confusion, so we rename these functions
that send HCI commands to be more similar in naming to the actual HCI
commands that will be sent.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 57f5d0d1d9f8e59819cb0ab4b707364c54b5b2d1 |
|
28-Jul-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Remove some functions from being exported
Some connection related functions are only used inside hci_conn.c
so no need to have them exported.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| d300fa9b14549c64e63691356c68483bcfeb0f04 |
|
19-Jun-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Route traffic only through BR/EDR controller
If AMP controller is first in the list then Bluetooth traffic might
be routed through it (if source is not specified). The patch
prevents this case and also checks that source is BR/EDR.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 38b3fef1730319e2730af3fc9f73698e3a9aeb4a |
|
15-Jun-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Improve debugging messages for hci_conn
Improve debugging of hci_conn objects by: adding print to hci_conn
refcounting, adding object spcifier when missing, change conn to hcon
since conn is heavily used for l2cap_conn objects and this is misleading.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| dfc94dbdb999154dc2ff44e6011a4912c0b29e88 |
|
30-May-2012 |
Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> |
Bluetooth: Allow only one LE connection attempt
Only one outgoing LE connection attempt should be possible.
hci_connect() will now return -EBUSY in case there's another pending
outgoing connection.
Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 9740e49d17e55f3832661fd99a8e0a17e921a82e |
|
29-May-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: A2MP: AMP Manager basic functions
Define AMP Manager and some basic functions.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
| 82781e634f815e9a675ef643a5e11da0cf77ce0e |
|
25-May-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Use __constant modifier in HCI code
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 8449e381a8558fb1d911017ea26bae681fea4240 |
|
23-May-2012 |
Gustavo Padovan <gustavo.padovan@collabora.co.uk> |
Bluetooth: Remove unneeded EXPORT_SYMBOL
After l2cap, sco and bluetooth modules merge some symbols doesn't need to
be exported anymore.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 8c520a59927a5600973782505dbb750d985057c4 |
|
23-May-2012 |
Gustavo Padovan <gustavo.padovan@collabora.co.uk> |
Bluetooth: Remove unnecessary headers include
Most of the include were unnecessary or already included by some other
header.
Replace module.h by export.h where possible.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 8fc9ced398824739d3c25c8aa7f6f34d8e7a49d9 |
|
23-May-2012 |
Gustavo Padovan <gustavo.padovan@collabora.co.uk> |
Bluetooth: Fix coding style in the subsystem
This is some leftover from the last patches that fixed style. It is mostly
line over 80 characters fixes reported by checkpatch.pl.
checkpatch.pl is clean for these files now.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| fc5fef615a963c8b13abf0bbc2a8e8d7c3fd1ffb |
|
23-May-2012 |
Gustavo Padovan <gustavo.padovan@collabora.co.uk> |
Bluetooth: Remove 'register' usage from the subsystem
Let the compiler chooses what is best.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 4f42a8cd4905e69ba4dd694d9338aeee1bb7e9ab |
|
23-May-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: trivial: Remove empty line
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 5974e4c469658696e6e0ce8951a59a61b122415a |
|
17-May-2012 |
Gustavo Padovan <gustavo.padovan@collabora.co.uk> |
Bluetooth: Fix coding style in hci_conn.c
Follow net subsystem rules.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 2ee8ce35b1e8ba2523fa4c45fa19f9dbe321f008 |
|
20-Apr-2012 |
Syam Sidhardhan <s.syam@samsung.com> |
Bluetooth: Remove unused hci_le_ltk_neg_reply()
No one is using hci_le_ltk_neg_reply() in bluetooth subsystem.
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Signed-off-by: Gustavo Padovan <gustavo@padovan.org>
|
| e10b9969f217c948c5523045f44eba4d3a758ff0 |
|
12-Apr-2012 |
Syam Sidhardhan <s.syam@samsung.com> |
Bluetooth: Remove unused hci_le_ltk_reply()
In this API, we were using sizeof operator for an array
given as function argument, which is invalid.
However this API is not used anywhere.
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Signed-off-by: Gustavo Padovan <gustavo@padovan.org>
|
| b12f62cfd9f46ac70013ce661640174b489efd39 |
|
25-Apr-2012 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Add dst_type parameter to hci_connect
This patch adds the dst_type parameter to hci_connect function.
Instead of searching the address type in advertising cache, we
use the dst_type parameter to establish LE connections.
The dst_type is ignored for BR/EDR connection establishment.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Acked-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| b29050448a7efcedf5e8bec71c371169389a7a26 |
|
24-Apr-2012 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Remove useless code in hci_connect
This patch removes unneeded variable assignments in hci_connect.
'sec_level' is already assigned to BT_SECURITY_LOW in hci_le_connect
and 'pending_sec_level' and 'auth_type' are assigned right after
if statement.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 9f0caeb1deafa9a894ee03134f6642c3a245b1af |
|
20-Apr-2012 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Add support for reusing the same hci_conn for LE links
As most LE devices leave advertising mode when they enter the connected
state, we may want to "pass" that connection to other users.
The first user will be the pairing procedure, the connection is
established without an associated socket, after the pairing is
complete, userspace may want to discover via GATT what services the
newly bonded device has.
If userspace establishes the connection while the timeout still
hasn't expired, the connection will be re-used.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Tested-by: João Paulo Rechi Vita <jprvita@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo@padovan.org>
|
| 9ffc93f203c18a70623f21950f1dd473c9ec48cd |
|
28-Mar-2012 |
David Howells <dhowells@redhat.com> |
Remove all #inclusions of asm/system.h
Remove all #inclusions of asm/system.h preparatory to splitting and killing
it. Performed with the following command:
perl -p -i -e 's!^#\s*include\s*<asm/system[.]h>.*\n!!' `grep -Irl '^#\s*include\s*<asm/system[.]h>' *`
Signed-off-by: David Howells <dhowells@redhat.com>
|
| 70c1f20b00495fd25b81be14b263d32648a3d629 |
|
22-Feb-2012 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Fix two minor style issues in HCI code
WARNING: min() should probably be min_t(__u16, scb->expect, count)
+ len = min(scb->expect, (__u16)count);
WARNING: Statements terminations use 1 semicolon
+ INIT_LIST_HEAD(&conn->chan_list);;
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 040030ef7d907107e6489b39da518bdf94136d68 |
|
20-Feb-2012 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Remove HCI notifier handling
The HCI notifier handling was never used outside of Bluetooth core layer
and thus remove it and replace it with direct function calls. Also move
the stack internal event generation into the HCI socket layer.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 48c7aba91f372251867d15efc9cf694ceee2de02 |
|
19-Feb-2012 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Fix hci_connect error return values
The hci_connect function should either return a valid hci_conn pointer
or a ERR_PTR() but never NULL. This patch fixes the two places where
hci_conn_add failures would have caused a NULL return. The only reason
for failure with hci_conn_add is memory allocation so ENOMEM seems to be
a good choice here.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
|
| 42d2d87cfe837e987802588f8d8b119a76714a74 |
|
17-Feb-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Prefix hex numbers with object name
Several hex numbers were printed without object name which
complicates debugging.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| e05dcc3291dcfe9ab1b456f38ccb3041ebbda59c |
|
17-Feb-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Use symbolic names for state in debug
Use state_to_string function in debug statements.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 18daf1644e634bae951a6e3d4d19d89170209762 |
|
13-Jan-2012 |
Peter Hurley <peter@hurleysoftware.com> |
Bluetooth: Fix l2cap conn failures for ssp devices
Commit 330605423c fixed l2cap conn establishment for non-ssp remote
devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security
is tested (which was always returning failure on any subsequent
security checks).
However, this broke l2cap conn establishment for ssp remote devices
when an ACL link was already established at SDP-level security. This
fix ensures that encryption must be pending whenever authentication
is also pending.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 2a5a5ec620a29d4ba07743c3151cdf0a417c8f8c |
|
02-Feb-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Use list _safe deleting from conn chan_list
Fixes possible bug when deleting element from the list in
function hci_chan_list_flush. list_for_each_entry_rcu is used
and after deleting element from the list we also free pointer
and then list_entry_rcu is taken from freed pointer.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 3c4e0df028935618d052235ba85bc7079be13394 |
|
02-Feb-2012 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Use list _safe deleting from conn_hash_list
Use list_for_each_entry_safe which is safe version against removal
of list entry. Otherwise we remove hci_conn element and reference
next element which result in accessing LIST_POISON.
[ 95.571834] Bluetooth: unknown link type 127
[ 95.578349] BUG: unable to handle kernel paging request at 20002000
[ 95.580236] IP: [<20002000>] 0x20001fff
[ 95.580763] *pde = 00000000
[ 95.581196] Oops: 0000 [#1] SMP
...
[ 95.582298] Pid: 3355, comm: hciconfig Tainted: G O 3.2.0-VirttualBox
[ 95.582298] EIP: 0060:[<20002000>] EFLAGS: 00210206 CPU: 0
[ 95.582298] EIP is at 0x20002000
...
[ 95.582298] Call Trace:
[ 95.582298] [<f8231ab6>] ? hci_conn_hash_flush+0x76/0xf0 [bluetooth]
[ 95.582298] [<f822bcb1>] hci_dev_do_close+0xc1/0x2e0 [bluetooth]
[ 95.582298] [<f822d679>] ? hci_dev_get+0x69/0xb0 [bluetooth]
[ 95.582298] [<f822e1da>] hci_dev_close+0x2a/0x50 [bluetooth]
[ 95.582298] [<f824102f>] hci_sock_ioctl+0x1af/0x3f0 [bluetooth]
[ 95.582298] [<c11153ea>] ? handle_pte_fault+0x8a/0x8f0
[ 95.582298] [<c146becf>] sock_ioctl+0x5f/0x260
[ 95.582298] [<c146be70>] ? sock_fasync+0x90/0x90
[ 95.582298] [<c1152b33>] do_vfs_ioctl+0x83/0x5b0
[ 95.582298] [<c1563f87>] ? do_page_fault+0x297/0x500
[ 95.582298] [<c1563cf0>] ? spurious_fault+0xd0/0xd0
[ 95.582298] [<c107165b>] ? up_read+0x1b/0x30
[ 95.582298] [<c1563f87>] ? do_page_fault+0x297/0x500
[ 95.582298] [<c100aa9f>] ? init_fpu+0xef/0x160
[ 95.582298] [<c15617c0>] ? do_debug+0x180/0x180
[ 95.582298] [<c100a958>] ? fpu_finit+0x28/0x80
[ 95.582298] [<c11530e7>] sys_ioctl+0x87/0x90
[ 95.582298] [<c156795f>] sysenter_do_call+0x12/0x38
...
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| b7d05bad1c10a363b6b99f66ac1fa76b6892e618 |
|
13-Jan-2012 |
Peter Hurley <peter@hurleysoftware.com> |
Bluetooth: Fix l2cap conn failures for ssp devices
Commit 330605423c fixed l2cap conn establishment for non-ssp remote
devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security
is tested (which was always returning failure on any subsequent
security checks).
However, this broke l2cap conn establishment for ssp remote devices
when an ACL link was already established at SDP-level security. This
fix ensures that encryption must be pending whenever authentication
is also pending.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| e72acc13c770a82b4ce4a07e9716f29320eae0f8 |
|
27-Jan-2012 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Remove unneeded locking
We don't need locking hdev in hci_conn_timeout() since it doesn't
access any hdev's shared resources, it basically queues HCI commands.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Reviewed-by: Ulisses Furquim <ulisses@profusion.mobi>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| 75d7735c7a3ddc3842473219460285748d10db11 |
|
30-Jan-2012 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Use GFP_KERNEL in hci_chan_create()
This function is called in process context only, so it should use
GFP_KERNEL to allocate memory.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| cb601d7e65f497a2a172d65b2ef1d738ac6fe4f4 |
|
30-Jan-2012 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Use GFP_KERNEL in hci_conn_add()
This function is called in process context only, so it should use
GFP_KERNEL to allocate memory.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
| aa64a8b500e61c33c17f1d5e7de0cc154489c59e |
|
18-Jan-2012 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Add a convenience function to check for SSP enabled
It's a very common test to see if both the local and the remote device
have SSP enabled. By creating a simple function to test this we can
shorten many if-statements in the code.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
|
| 84bde9d6c0e6830f4a8685a5d237965053118bf9 |
|
25-Jan-2012 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Convert hdev->ssp_mode to a flag
The ssp_mode is essentially just a boolean so it's more appropriate to
have it simply as a flag in hdev->dev_flags.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
|
| 58a681ef1455aef9caad1d41073868fb399373f6 |
|
16-Jan-2012 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Merge boolean members of struct hci_conn into flags
Now that the flags member of struct hci_conn is supposed to accommodate
any boolean type values we can easily merge all boolean members into it.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
|
| a0c808b373e89aecc3ecae4cbdcdeff68aa12e3e |
|
16-Jan-2012 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Convert hdev->out to a bool type
The hdev->out variable is essentially a boolean so the type 'bool' makes
more sense than u8.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
|
| 51a8efd7d02c13cb1c6fdd1cd66788792a3fcc7c |
|
16-Jan-2012 |
Johan Hedberg <johan.hedberg@intel.com> |
Bluetooth: Rename conn->pend to conn->flags
These flags can and will be used for more general purpose values than
just pending state transitions so the more common name "flags" makes
more sense than "pend".
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
|
| f20d09d5f7093e5dc5f231c65835e2d04739bd5e |
|
22-Dec-2011 |
Gustavo F. Padovan <padovan@profusion.mobi> |
Bluetooth: remove *_bh usage from hci_dev_list and hci_cb_list
They don't need to disable interrupts anymore, we only run in process
context now.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| d7660918fce210f421cc58c060ca3de71e4ffd37 |
|
19-Dec-2011 |
Gustavo F. Padovan <padovan@profusion.mobi> |
Revert "Bluetooth: Revert: Fix L2CAP connection establishment"
This reverts commit 4dff523a913197e3314c7b0d08734ab037709093.
It was reported that this patch cause issues when trying to connect to
legacy devices so reverting it.
Reported-by: David Fries <david@fries.net>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 3c54711c4fd103edf2044ab60726939f1de02b0c |
|
15-Dec-2011 |
Gustavo F. Padovan <padovan@profusion.mobi> |
Bluetooth: Don't disable tasklets to call hdev->notify()
It's pointless, we aren't protecting anything since btusb_notify()
schedules a work to run, then all it operation happens without protection.
If protection is really needed here, we will fix it further.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| bf4c63252490ba78fb833cc7acf1a5b1900c970f |
|
15-Dec-2011 |
Gustavo F. Padovan <padovan@profusion.mobi> |
Bluetooth: convert conn hash to RCU
Handling hci_conn_hash with RCU make us avoid some locking and disable
tasklets.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 8192edef03f9b47f1cc1120724db525e63e218f3 |
|
14-Dec-2011 |
Gustavo F. Padovan <padovan@profusion.mobi> |
Bluetooth: Use RCU to manipulate chan_list
Instead of using tasklet_disable() to prevent acess to the channel use, we
can use RCU and improve the performance of our code.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| b9cc553f12d14b692d0fcb607d28db783da68139 |
|
17-Jun-2011 |
Gustavo F. Padovan <padovan@profusion.mobi> |
Bluetooth: hci_conn_auto_accept() doesn't need locking
It doesn't really touch any sensitive information about hdev. So no need
to lock here.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 19c40e3bcaf2d969f5d4ee85bbe1330b54d36d9c |
|
17-Jun-2011 |
Gustavo F. Padovan <padovan@profusion.mobi> |
Bluetooth: Use delayed_work for connection timeout
Bluetooth rx task runs now in a workqueue, so it a good approach run any
timer that share locking with process context code also in a workqueue.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 09fd0de5bd8f8ef3317e5365f92f1a13dcd89aa9 |
|
17-Jun-2011 |
Gustavo F. Padovan <padovan@profusion.mobi> |
Bluetooth: Replace spin_lock by mutex in hci_dev
Now we run everything in HCI in process context, so it's a better idea use
mutex instead spin_lock. The macro remains hci_dev_lock() (and I got rid
of hci_dev_lock_bh()), of course.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 416dc94baa4a0de6904707d17522f7eae7778c8e |
|
07-Dec-2011 |
Gustavo F. Padovan <padovan@profusion.mobi> |
Bluetooth: make hci_conn_enter_sniff_mode static
It isn't used outside hci_conn.c
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 3e9c40a6f72a4ee7a978204cac00f91ad08bbe9b |
|
15-Dec-2011 |
Gustavo F. Padovan <padovan@profusion.mobi> |
Bluetooth: Use list_for_each_entry in hci_conn_hash_flush()
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 2c33c06a8fd2f784ca763ad150d5d63c3c49946e |
|
14-Dec-2011 |
Gustavo F. Padovan <padovan@profusion.mobi> |
Bluetooth: remove struct hci_chan_hash
Only the list member of the struct was used, so we now fold it into
hci_conn.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| d095c1ebd43a43c1d78055ff111f464b04f8624e |
|
01-Dec-2011 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Remove magic bluetooth version numbers
Use bluetooth names instead of BT SIG assigned numbers
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 9f5a0d7bf079e9e26771ad13ff1c2cb3adf80963 |
|
07-Nov-2011 |
Andrei Emeltchenko <andrei.emeltchenko@intel.com> |
Bluetooth: Define HCI reasons instead of magic number
Use HCI error reasons instead of magic numbers.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 73d80deb7bdf0171f22e76dc2429c1f99eff90e2 |
|
02-Nov-2011 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: prioritizing data over HCI
This implement priority based scheduler using skbuffer priority set via
SO_PRIORITY socket option.
It introduces hci_chan_hash (list of HCI Channel/hci_chan) per connection,
each item in this list refer to a L2CAP connection and it is used to
queue the data for transmission.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 8035ded466049ca2fe8c04564a0fa00f222abe3f |
|
01-Nov-2011 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: replace list_for_each with list_for_each_entry whenever possible
When all items in the list have the same type there is no much of a point
to use list_for_each except if you want to use the list pointer itself.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 4dff523a913197e3314c7b0d08734ab037709093 |
|
26-Oct-2011 |
Arek Lichwa <arkadiusz.lichwa@tieto.com> |
Bluetooth: Revert: Fix L2CAP connection establishment
This reverts commit 330605423ca6eafafb8dcc27502bce1c585d1b06.
The commit introduces regression when two 2.1 devices attempt
establish rfcomm channel. Such connection is refused since there's
a security block issue on l2cap. It means the link is unencrypted.
2011-09-16 18:08:46.567616 < ACL data: handle 1 flags 0x00 dlen 24
0000: 14 00 40 00 06 00 02 00 0f 35 03 19 12 00 ff ff
..@......5....˙˙
0010: 35 05 0a 00 00 ff ff 00 5....˙˙.
2011-09-16 18:08:46.572377 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 1 packets 1
2011-09-16 18:08:46.577931 > ACL data: handle 1 flags 0x02 dlen 88
L2CAP(d): cid 0x0040 len 84 [psm 0]
0000: 07 00 02 00 4f 00 4c 35 4a 35 48 09 00 00 0a 00
....O.L5J5H.....
0010: 01 00 00 09 00 01 35 03 19 12 00 09 00 05 35 03
......5.......5.
0020: 19 10 02 09 00 09 35 08 35 06 19 12 00 09 01 02
......5.5.......
0030: 09 02 00 09 01 02 09 02 01 09 00 0a 09 02 02 09
................
0040: 00 00 09 02 03 09 00 00 09 02 04 28 01 09 02 05
...........(....
0050: 09 00 02 00 ....
2011-09-16 18:08:46.626057 < HCI Command: Authentication Requested
(0x01|0x0011) plen 2
handle 1
2011-09-16 18:08:46.627614 > HCI Event: Command Status (0x0f) plen 4
Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
2011-09-16 18:08:46.627675 > HCI Event: Link Key Request (0x17) plen 6
bdaddr 00:00:F2:6A:29:69
2011-09-16 18:08:46.634999 < HCI Command: Link Key Request Reply
(0x01|0x000b) plen 22
bdaddr 00:00:F2:6A:29:69 key 58CD393179FC902E5E8F512A855EE532
2011-09-16 18:08:46.683278 > HCI Event: Command Complete (0x0e) plen 10
Link Key Request Reply (0x01|0x000b) ncmd 1
status 0x00 bdaddr 00:00:F2:6A:29:69
2011-09-16 18:08:46.764729 > HCI Event: Auth Complete (0x06) plen 3
status 0x00 handle 1
2011-09-16 18:08:46.764821 < ACL data: handle 1 flags 0x00 dlen 12
0000: 08 00 01 00 02 05 04 00 03 00 41 00 ..........A.
2011-09-16 18:08:46.764851 > HCI Event: Command Status (0x0f) plen 4
Unknown (0x00|0x0000) status 0x00 ncmd 2
2011-09-16 18:08:46.768117 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 1 packets 1
2011-09-16 18:08:46.770894 > ACL data: handle 1 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0041 result 3 status 0
Connection refused - security block
2011-09-16 18:08:49.000691 < ACL data: handle 1 flags 0x00 dlen 12
0000: 08 00 01 00 06 06 04 00 40 00 40 00 ........@.@.
2011-09-16 18:08:49.015675 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 1 packets 1
2011-09-16 18:08:49.016927 > ACL data: handle 1 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
2011-09-16 18:08:51.009480 < HCI Command: Disconnect (0x01|0x0006) plen
3
handle 1 reason 0x13
Reason: Remote User Terminated Connection
2011-09-16 18:08:51.011525 > HCI Event: Command Status (0x0f) plen 4
Disconnect (0x01|0x0006) status 0x00 ncmd 1
2011-09-16 18:08:51.123494 > HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 1 reason 0x16
Reason: Connection Terminated by Local Host
Signed-off-by: Arek Lichwa <arkadiusz.lichwa@tieto.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 0e8339151fa85cb9b088abfb13e2dd5214a25429 |
|
27-Jul-2011 |
Anderson Lizardo <anderson.lizardo@openbossa.org> |
Bluetooth: use recommended LE connection parameters
The new connection parameters now match the recommended values for
Proximity and Health Thermometer profiles. The previous values were
ramdomly chosen, and are either too low or too high for most cases.
New values:
Scan Interval: 60 ms
Scan Window: 30 ms
Minimum Connection Interval: 50 ms
Maximum Connection Interval: 70 ms
Supervision Timeout: 420 ms
See "Table 5.2: Recommended Scan Interval and Scan Window Values" and
"Table 5.3: Recommended Connection Interval Values" for both profiles
for details. Note that the "fast connection" parameters were chosen,
because we do not support yet dynamically changing these parameters from
initiator side.
Additionally, the Proximity profile recommends (section "4.4 Alert on
Link Loss"):
"It is recommended that the Link Supervision Timeout (LSTO) is set to 6x
the connection interval."
Minimum_CE_Length and Maximum_CE_Length were also changed from 0x0001 to
0x0000 because they are informational and optional, and old value was
not reflecting reality.
Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 51beabdf624df14d0805b001d3f939629b70d9db |
|
19-Sep-2011 |
Anderson Briglia <anderson.briglia@openbossa.org> |
Bluetooth: Fix wrong memcpy size on LE start encryption
This patch fixes wrong memcpy size when copying rand value to
HCI_OP_LE_START_ENC command.
The compiler pretends that the array parameter was declared as a pointer
and sizeof reports the size of the pointer. [1]
[1] http://www.c-faq.com/aryptr/aryparmsize.html
Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 163f4dabea4e3be485c17e8f08e3a6468ad31cbf |
|
30-Jun-2011 |
Tomas Targownik <ttargownik@geicp.com> |
Bluetooth: Fix memory leak under page timeouts
If the remote device is not present, the connections attemp fails and
the struct hci_conn was not freed
Signed-off-by: Tomas Targownik <ttargownik@geicp.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 330605423ca6eafafb8dcc27502bce1c585d1b06 |
|
15-Jun-2011 |
Ilia Kolomisnky <ilia.kolominsky@gmail.com> |
Bluetooth: Fix L2CAP connection establishment
In hci_conn_security ( which is used during L2CAP connection
establishment ) test for HCI_CONN_ENCRYPT_PEND state also
sets this state, which is bogus and leads to connection time-out
on L2CAP sockets in certain situations (especially when
using non-ssp devices )
Signed-off-by: Ilia Kolomisnky <iliak@ti.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 7b5c0d5242295a3b52e7161bf129e2f0e8c624cb |
|
09-Jun-2011 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Fix initial security level of LE links
As the default security level (BT_SECURITY_SDP) doesn't make sense for
LE links, initialize LE links with something that makes sense.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| a7a595f675f1b33dc73167147321dba5c4395acc |
|
09-Jun-2011 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Add support for LE Start Encryption
This adds support for starting SMP Phase 2 Encryption, when the initial
SMP negotiation is successful. This adds the LE Start Encryption and LE
Long Term Key Request commands and related events.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 6fdf658c9a0e51e6663f2769f6d310c2843a862b |
|
13-Jun-2011 |
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Bluetooth: Fix L2CAP security check
With older userspace versions (using hciops) it might not have the
key type to check if the key has sufficient security for any security
level so it is necessary to check the return of hci_conn_auth to make
sure the connection is authenticated
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Acked-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| ef4177e2bf92543e422fae154888062376e2283d |
|
02-Jun-2011 |
Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com> |
Bluetooth: Simplify hci_conn_accept_secure check
If the link key is secure (authenticated or combination 16 digit)
the sec_level will be always BT_SECURITY_HIGH. Therefore, instead
of checking the link key type simply check the sec_level on the link.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 14b12d0b98f87162b7e9e93dde66d1af97886567 |
|
24-May-2011 |
Jaikumar Ganesh <jaikumar@google.com> |
Bluetooth: Add BT_POWER L2CAP socket option.
Add BT_POWER socket option used to control the power
characteristics of the underlying ACL link. When the remote end
has put the link in sniff mode and the host stack wants to send
data we need need to explicitly exit sniff mode to work well with
certain devices (For example, A2DP on Plantronics Voyager 855).
However, this causes problems with HID devices.
Hence, moving into active mode when sending data, irrespective
of who set the sniff mode has been made as a socket option. By
default, we will move into active mode. HID devices can set the
L2CAP socket option to prevent this from happening.
Currently, this has been implemented for L2CAP sockets. This has been
tested with incoming and outgoing L2CAP sockets for HID and A2DP.
Based on discussions on linux-bluetooth and patches submitted by
Andrei Emeltchenko.
Signed-off-by: Jaikumar Ganesh <jaikumar@google.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 6d3ce0e7902314ddb330deaf8827205881d7e59f |
|
31-May-2011 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Set 'peer_addr_type' in hci_le_connect()
Set the 'peer_addr_type' field of the LE Create Connection command
sent in hci_le_connect().
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| eda42b503a3c866d51146549fe46da1f5f64e2c7 |
|
31-May-2011 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Check advertising cache in hci_connect()
When connecting to a LE device, we need to check the advertising
cache in order to know the address type of that device.
If its advertising entry is not found, the connection is not
established and hci_connect() returns error.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 893d67514aebcfd3ebf17bd212ceea1e2741a443 |
|
31-May-2011 |
Andre Guedes <andre.guedes@openbossa.org> |
Bluetooth: Remove useless check in hci_connect()
There is no need to check the connection's state since hci_conn_add()
has just created a new connection and its state has been set properly.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 19f8def031bfa50c579149b200bfeeb919727b27 |
|
31-May-2011 |
Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com> |
Bluetooth: Fix auth_complete_evt for legacy units
Legacy devices don't re-authenticate the link properly if a link key
already exists. Thus, don't update sec_level for this case even if
hci_auth_complete_evt indicates success. Otherwise the sec_level will
not reflect a real security on the link.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| b3b1b061583ba4909b59a2f736825d86495fe956 |
|
06-May-2011 |
Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com> |
Bluetooth: Double check sec req for pre 2.1 device
In case of pre v2.1 devices authentication request will return
success immediately if the link key already exists without any
authentication process.
That means, it's not possible to re-authenticate the link if you
already have combination key and for instance want to re-authenticate
to get the high security (use 16 digit pin).
Therefore, it's necessary to check security requirements on auth
complete event to prevent not enough secure connection.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 9f61656a60c9506e3e4cd41af5efbcf6a30ee3b9 |
|
28-Apr-2011 |
Johan Hedberg <johan.hedberg@nokia.com> |
Bluetooth: Add variable SSP auto-accept delay support
Some test systems require an arbitrary delay to the auto-accept test
cases for Secure Simple Pairing in order for the tests to pass.
Previously when this was handled in user space it was worked around by
code modifications and recompilation, but now that it's on the kernel
side it's more convenient if there's a debugfs interface for it.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 13d39315c22b128f4796fc008b04914a7c32bb1a |
|
28-Apr-2011 |
Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com> |
Bluetooth: Map sec_level to link key requirements
Keep the link key type together with connection and use it to
map security level to link key requirements. Authenticate and/or
encrypt connection if the link is insufficiently secure.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 30e7627219f985cd17a1ac24e0163ebcfb1277bf |
|
22-Feb-2011 |
Ville Tervo <ville.tervo@nokia.com> |
Bluetooth: Use ERR_PTR as return error from hci_connect
Use ERR_PTR mechanism to return error from hci_connect.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 15c4794fe247d85ce38eb5f5e2a5855d996f56cd |
|
21-Feb-2011 |
Anderson Briglia <anderson.briglia@openbossa.org> |
Bluetooth: Fix LE conn creation
This patch prevents a crash when remote host tries to create a LE
link which already exists. i.e.: call l2test twice passing the
same parameters.
Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| a958355699dd90ba69951bdf55dda00e3e97222c |
|
19-Feb-2011 |
Johan Hedberg <johan.hedberg@nokia.com> |
Bluetooth: Fix inititial value for remote authentication requirements
The remote authentication requirements for conections need to be
initialized to 0xff (unknown) since it is possible that we receive a IO
Capability Request before we have received information about the remote
requirements.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 2ce603ebe1f1420c7c5b013638ec29b4fc975180 |
|
16-Feb-2011 |
Claudio Takahasi <claudio.takahasi@openbossa.org> |
Bluetooth: Send LE Connection Update Command
If the new connection update parameter are accepted, the LE master
host sends the LE Connection Update Command to its controller informing
the new requested parameters.
Signed-off-by: Claudio Takahasi <claudio.takahasi@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| b92a62238ff2d3fb88cf0f6de454f3d1b4ae5d52 |
|
11-Feb-2011 |
Vinicius Costa Gomes <vinicius.gomes@openbossa.org> |
Bluetooth: Fix initiated LE connections
Fix LE connections not being marked as master.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 6ed58ec520ad2b2fe3f955c8a5fd0eecafccebdf |
|
11-Feb-2011 |
Ville Tervo <ville.tervo@nokia.com> |
Bluetooth: Use LE buffers for LE traffic
Bluetooth chips may have separate buffers for LE traffic.
This patch add support to use LE buffers provided by the chip.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| fcd89c09a59a054fb986861e0862aa2fff7d7c40 |
|
11-Feb-2011 |
Ville Tervo <ville.tervo@nokia.com> |
Bluetooth: Add LE connect support
Bluetooth V4.0 adds support for Low Energy (LE) connections.
Specification introduces new set of hci commands to control LE
connection. This patch adds logic to create, cancel and disconnect
LE connections.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 17fa4b9dff72fb3a1a68cc80caf98fc941d2b8b3 |
|
25-Jan-2011 |
Johan Hedberg <johan.hedberg@nokia.com> |
Bluetooth: Add set_io_capability management command
This patch adds a new set_io_capability management command which is used
to set the IO capability for Secure Simple Pairing (SSP) as well as the
Security Manager Protocol (SMP). The value is per hci_dev and each
hci_conn object inherits it upon creation.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 765c2a964b49bd06b61a52991519281c85d82b67 |
|
18-Jan-2011 |
Johan Hedberg <johan.hedberg@nokia.com> |
Bluetooth: Fix race condition with conn->sec_level
The conn->sec_level value is supposed to represent the current level of
security that the connection has. However, by assigning to it before
requesting authentication it will have the wrong value during the
authentication procedure. To fix this a pending_sec_level variable is
added which is used to track the desired security level while making
sure that sec_level always represents the current level of security.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 65cf686ee102b7eb0477a4bab82ff227071a0258 |
|
18-Jan-2011 |
Johan Hedberg <johan.hedberg@nokia.com> |
Bluetooth: Fix MITM protection requirement preservation
If an existing connection has a MITM protection requirement (the first
bit of the auth_type) then that requirement should not be cleared by new
sockets that reuse the ACL but don't have that requirement.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 88644bb9fee591b2743a881923263bc28df4cded |
|
18-Jan-2011 |
Johan Hedberg <johan.hedberg@nokia.com> |
Revert "Bluetooth: Update sec_level/auth_type for already existing connections"
This reverts commit 045309820afe047920a50de25634dab46a1e851d. That
commit is wrong for two reasons:
- The conn->sec_level shouldn't be updated without performing
authentication first (as it's supposed to represent the level of
security that the existing connection has)
- A higher auth_type value doesn't mean "more secure" like the commit
seems to assume. E.g. dedicated bonding with MITM protection is 0x03
whereas general bonding without MITM protection is 0x04. hci_conn_auth
already takes care of updating conn->auth_type so hci_connect doesn't
need to do it.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| 70f23020e6d89155504b5b39f22505f4aec6fa6f |
|
01-Dec-2010 |
Andrei Emeltchenko <andrei.emeltchenko@nokia.com> |
Bluetooth: clean up hci code
Do not use assignment in IF condition, remove extra spaces,
fixing typos, simplify code.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| e73439d8c0e4c522c843b8bb98c0eb5700da6b05 |
|
26-Jul-2010 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Defer SCO setup if mode change is pending
Certain headsets such as the Motorola H350 will reject SCO and eSCO
connection requests while the ACL is transitioning from sniff mode
to active mode. Add synchronization so that SCO and eSCO connection
requests will wait until the ACL has fully transitioned to active mode.
< HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2
handle 12
> HCI Event: Command Status (0x0f) plen 4
Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
< HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
handle 12 voice setting 0x0040
> HCI Event: Command Status (0x0f) plen 4
Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 1
> HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 12 mode 0x00 interval 0
Mode: Active
> HCI Event: Synchronous Connect Complete (0x2c) plen 17
status 0x10 handle 14 bdaddr 00:1A:0E:50:28:A4 type SCO
Error: Connection Accept Timeout Exceeded
Signed-off-by: Ron Shaffer <rshaffer@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 2d0a03460a8a0c611843500735096ff799aa8510 |
|
28-May-2010 |
Ron Shaffer <rshaffer@codeaurora.org> |
Bluetooth: Reassigned copyright to Code Aurora Forum
Qualcomm, Inc. has reassigned rights to Code Aurora Forum. Accordingly,
as files are modified by Code Aurora Forum members, the copyright
statement will be updated.
Signed-off-by: Ron Shaffer <rshaffer@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 045309820afe047920a50de25634dab46a1e851d |
|
15-Jun-2010 |
Ville Tervo <ville.tervo@nokia.com> |
Bluetooth: Update sec_level/auth_type for already existing connections
Update auth level for already existing connections if it is lower
than required by new connection.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
Reviewed-by: Emeltchenko Andrei <andrei.emeltchenko@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| c390216b3e868b16d8154939f4b6f8c16dbd9a9f |
|
13-Nov-2009 |
Nick Pelly <npelly@google.com> |
Bluetooth: Enter active mode before establishing a SCO link.
When in sniff mode with a long interval time (1.28s) it can take 4+ seconds
to establish a SCO link. Fix by requesting active mode before requesting
SCO connection. This improves SCO setup time to ~500ms.
Bluetooth headsets that use a long interval time, and exhibit the long
SCO connection time include Motorola H790, HX1 and H17. They have a
CSR 2.1 chipset.
Verified this behavior and fix with host Bluetooth chipsets: BCM4329 and
TI1271.
2009-10-13 14:17:46.183722 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 1 mode 0x02 interval 2048
Mode: Sniff
2009-10-13 14:17:53.436285 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
handle 1 voice setting 0x0060
2009-10-13 14:17:53.445593 > HCI Event: Command Status (0x0f) plen 4
Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
2009-10-13 14:17:57.788855 > HCI Event: Synchronous Connect Complete 0x2c) plen 17
status 0x00 handle 257 bdaddr 00:1A:0E:F1:A4:7F type eSCO
Air mode: CVSD
Signed-off-by: Nick Pelly <npelly@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 93f19c9fc8c98bb6d2e9825115989603ffd5cd1f |
|
02-Sep-2009 |
Andrei Emeltchenko <andrei.emeltchenko@nokia.com> |
Bluetooth: Set general bonding security for ACL by default
This patch fixes double pairing issues with Secure Simple
Paring support. It was observed that when pairing with SSP
enabled, that the confirmation will be asked twice.
http://www.spinics.net/lists/linux-bluetooth/msg02473.html
This also causes bug when initiating SSP connection from
Windows Vista.
The reason is because bluetoothd does not store link keys
since HCIGETAUTHINFO returns 0. Setting default to general
bonding fixes these issues.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 9eba32b86d17ef87131fa0bce43c614904ab5781 |
|
22-Aug-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Add extra device reference counting for connections
The device model itself has no real usable reference counting at the
moment and this causes problems if parents are deleted before their
children. The device model itself handles the memory details of this
correctly, but the uevent order is not consistent. This causes various
problems for systems like HAL or even X.
So until device_put() does a proper cleanup, the device for Bluetooth
connection will be protected with an extra reference counting to ensure
the correct order of uevents when connections are terminated.
This is not an automatic feature. Higher Bluetooth layers like HIDP or
BNEP should grab this new reference to ensure that their uevents are
send before the ones from the parent device.
Based on a report by Brian Rogers <brian@xyzw.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 1b0336bb36f88976f1210a65b62f6a3e9578ee7b |
|
09-May-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Don't use hci_acl_connect_cancel() for incoming connections
The connection setup phase takes around 2 seconds or longer and in
that time it is possible that the need for an ACL connection is no
longer present. If that happens then, the connection attempt will
be canceled.
This only applies to outgoing connections, but currently it can also
be triggered by incoming connection. Don't call hci_acl_connect_cancel()
on incoming connection since these have to be either accepted or rejected
in this state. Once they are successfully connected they need to be
fully disconnected anyway.
Also remove the wrong hci_acl_disconn() call for SCO and eSCO links
since at this stage they can't be disconnected either, because the
connection handle is still unknown.
Based on a report by Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Johan Hedberg <johan.hedberg@nokia.com>
|
| 384943ec1bb462e410390ad8f108ff1474cd882d |
|
09-May-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Fix wrong module refcount when connection setup fails
The module refcount is increased by hci_dev_hold() call in hci_conn_add()
and decreased by hci_dev_put() call in del_conn(). In case the connection
setup fails, hci_dev_put() is never called.
Procedure to reproduce the issue:
# hciconfig hci0 up
# lsmod | grep btusb -> "used by" refcount = 1
# hcitool cc <non-exisiting bdaddr> -> will get timeout
# lsmod | grep btusb -> "used by" refcount = 2
# hciconfig hci0 down
# lsmod | grep btusb -> "used by" refcount = 1
# rmmod btusb -> ERROR: Module btusb is in use
The hci_dev_put() call got moved into del_conn() with the 2.6.25 kernel
to fix an issue with hci_dev going away before hci_conn. However that
change was wrong and introduced this problem.
When calling hci_conn_del() it has to call hci_dev_put() after freeing
the connection details. This handling should be fully symmetric. The
execution of del_conn() is done in a work queue and needs it own calls
to hci_dev_hold() and hci_dev_put() to ensure that the hci_dev stays
until the connection cleanup has been finished.
Based on a report by Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Bing Zhao <bzhao@marvell.com>
|
| a67e899cf38ae542d1a028ccd021f9189f76fb74 |
|
03-May-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Fix issue with sysfs handling for connections
Due to a semantic changes in flush_workqueue() the current approach of
synchronizing the sysfs handling for connections doesn't work anymore. The
whole approach is actually fully broken and based on assumptions that are
no longer valid.
With the introduction of Simple Pairing support, the creation of low-level
ACL links got changed. This change invalidates the reason why in the past
two independent work queues have been used for adding/removing sysfs
devices. The adding of the actual sysfs device is now postponed until the
host controller successfully assigns an unique handle to that link. So
the real synchronization happens inside the controller and not the host.
The only left-over problem is that some internals of the sysfs device
handling are not initialized ahead of time. This leaves potential access
to invalid data and can cause various NULL pointer dereferences. To fix
this a new function makes sure that all sysfs details are initialized
when an connection attempt is made. The actual sysfs device is only
registered when the connection has been successfully established. To
avoid a race condition with the registration, the check if a device is
registered has been moved into the removal work.
As an extra protection two flush_work() calls are left in place to
make sure a previous add/del work has been completed first.
Based on a report by Marc Pignat <marc.pignat@hevs.ch>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Justin P. Mattock <justinmattock@gmail.com>
Tested-by: Roger Quadros <ext-roger.quadros@nokia.com>
Tested-by: Marc Pignat <marc.pignat@hevs.ch>
|
| 3fdca1e1370ffe89980927cdef0583bebcd8caaf |
|
28-Apr-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Fix connection establishment with low security requirement
The Bluetooth 2.1 specification introduced four different security modes
that can be mapped using Legacy Pairing and Simple Pairing. With the
usage of Simple Pairing it is required that all connections (except
the ones for SDP) are encrypted. So even the low security requirement
mandates an encrypted connection when using Simple Pairing. When using
Legacy Pairing (for Bluetooth 2.0 devices and older) this is not required
since it causes interoperability issues.
To support this properly the low security requirement translates into
different host controller transactions depending if Simple Pairing is
supported or not. However in case of Simple Pairing the command to
switch on encryption after a successful authentication is not triggered
for the low security mode. This patch fixes this and actually makes
the logic to differentiate between Simple Pairing and Legacy Pairing
a lot simpler.
Based on a report by Ville Tervo <ville.tervo@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 052b30b0a8eec8db5b18ad49effdf2a9ba4c1e1a |
|
26-Apr-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Add different pairing timeout for Legacy Pairing
The Bluetooth stack uses a reference counting for all established ACL
links and if no user (L2CAP connection) is present, the link will be
terminated to save power. The problem part is the dedicated pairing
when using Legacy Pairing (Bluetooth 2.0 and before). At that point
no user is present and pairing attempts will be disconnected within
10 seconds or less. In previous kernel version this was not a problem
since the disconnect timeout wasn't triggered on incoming connections
for the first time. However this caused issues with broken host stacks
that kept the connections around after dedicated pairing. When the
support for Simple Pairing got added, the link establishment procedure
needed to be changed and now causes issues when using Legacy Pairing
When using Simple Pairing it is possible to do a proper reference
counting of ACL link users. With Legacy Pairing this is not possible
since the specification is unclear in some areas and too many broken
Bluetooth devices have already been deployed. So instead of trying to
deal with all the broken devices, a special pairing timeout will be
introduced that increases the timeout to 60 seconds when pairing is
triggered.
If a broken devices now puts the stack into an unforeseen state, the
worst that happens is the disconnect timeout triggers after 120 seconds
instead of 4 seconds. This allows successful pairings with legacy and
broken devices now.
Based on a report by Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 2ae9a6be5f476f3512839a4d11a8f432bfd2914c |
|
21-Feb-2009 |
Dave Young <hidave.darkstar@gmail.com> |
Bluetooth: Move hci_conn_del_sysfs() back to avoid device destruct too early
The following commit introduce a regression:
commit 7d0db0a373195385a2e0b19d1f5e4b186fdcffac
Author: Marcel Holtmann <marcel@holtmann.org>
Date: Mon Jul 14 20:13:51 2008 +0200
[Bluetooth] Use a more unique bus name for connections
I get panic as following (by netconsole):
[ 2709.344034] usb 5-1: new full speed USB device using uhci_hcd and address 4
[ 2709.505776] usb 5-1: configuration #1 chosen from 1 choice
[ 2709.569207] Bluetooth: Generic Bluetooth USB driver ver 0.4
[ 2709.570169] usbcore: registered new interface driver btusb
[ 2845.742781] BUG: unable to handle kernel paging request at 6b6b6c2f
[ 2845.742958] IP: [<c015515c>] __lock_acquire+0x6c/0xa80
[ 2845.743087] *pde = 00000000
[ 2845.743206] Oops: 0002 [#1] SMP
[ 2845.743377] last sysfs file: /sys/class/bluetooth/hci0/hci0:6/type
[ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev
[ 2845.743742]
[ 2845.743742] Pid: 0, comm: swapper Not tainted (2.6.29-rc5-smp #54) Dell DM051
[ 2845.743742] EIP: 0060:[<c015515c>] EFLAGS: 00010002 CPU: 0
[ 2845.743742] EIP is at __lock_acquire+0x6c/0xa80
[ 2845.743742] EAX: 00000046 EBX: 00000046 ECX: 6b6b6b6b EDX: 00000002
[ 2845.743742] ESI: 6b6b6b6b EDI: 00000000 EBP: c064fd14 ESP: c064fcc8
[ 2845.743742] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 2845.743742] Process swapper (pid: 0, ti=c064e000 task=c05d1400 task.ti=c064e000)
[ 2845.743742] Stack:
[ 2845.743742] c05d1400 00000002 c05d1400 00000001 00000002 00000000 f65388dc c05d1400
[ 2845.743742] 6b6b6b6b 00000292 c064fd0c c0153732 00000000 00000000 00000001 f700fa50
[ 2845.743742] 00000046 00000000 00000000 c064fd40 c0155be6 00000000 00000002 00000001
[ 2845.743742] Call Trace:
[ 2845.743742] [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0
[ 2845.743742] [<c0155be6>] ? lock_acquire+0x76/0xa0
[ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742] [<c046c885>] ? _spin_lock_irqsave+0x45/0x80
[ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742] [<c03e1f94>] ? skb_queue_purge+0x14/0x20
[ 2845.743742] [<f8171f5a>] ? hci_conn_del+0x10a/0x1c0 [bluetooth]
[ 2845.743742] [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap]
[ 2845.743742] [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth]
[ 2845.743742] [<f8175758>] ? hci_event_packet+0x5f8/0x31c0 [bluetooth]
[ 2845.743742] [<c03dfe19>] ? sock_def_readable+0x59/0x80
[ 2845.743742] [<c046c14d>] ? _read_unlock+0x1d/0x20
[ 2845.743742] [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth]
[ 2845.743742] [<c015388b>] ? trace_hardirqs_on+0xb/0x10
[ 2845.743742] [<f816fa6a>] ? hci_rx_task+0x2ba/0x490 [bluetooth]
[ 2845.743742] [<c0133661>] ? tasklet_action+0x31/0xc0
[ 2845.743742] [<c013367c>] ? tasklet_action+0x4c/0xc0
[ 2845.743742] [<c0132eb7>] ? __do_softirq+0xa7/0x170
[ 2845.743742] [<c0116dec>] ? ack_apic_level+0x5c/0x1c0
[ 2845.743742] [<c0132fd7>] ? do_softirq+0x57/0x60
[ 2845.743742] [<c01333dc>] ? irq_exit+0x7c/0x90
[ 2845.743742] [<c01055bb>] ? do_IRQ+0x4b/0x90
[ 2845.743742] [<c01333d5>] ? irq_exit+0x75/0x90
[ 2845.743742] [<c010392c>] ? common_interrupt+0x2c/0x34
[ 2845.743742] [<c010a14f>] ? mwait_idle+0x4f/0x70
[ 2845.743742] [<c0101c05>] ? cpu_idle+0x65/0xb0
[ 2845.743742] [<c045731e>] ? rest_init+0x4e/0x60
[ 2845.743742] Code: 0f 84 69 02 00 00 83 ff 07 0f 87 1e 06 00 00 85 ff 0f 85 08 05 00 00 8b 4d cc 8b 49 04 85 c9 89 4d d4 0f 84 f7 04 00 00 8b 75 d4 <f0> ff 86 c4 00 00 00 89 f0 e8 56 a9 ff ff 85 c0 0f 85 6e 03 00
[ 2845.743742] EIP: [<c015515c>] __lock_acquire+0x6c/0xa80 SS:ESP 0068:c064fcc8
[ 2845.743742] ---[ end trace 4c985b38f022279f ]---
[ 2845.743742] Kernel panic - not syncing: Fatal exception in interrupt
[ 2845.743742] ------------[ cut here ]------------
[ 2845.743742] WARNING: at kernel/smp.c:329 smp_call_function_many+0x151/0x200()
[ 2845.743742] Hardware name: Dell DM051
[ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev
[ 2845.743742] Pid: 0, comm: swapper Tainted: G D 2.6.29-rc5-smp #54
[ 2845.743742] Call Trace:
[ 2845.743742] [<c012e076>] warn_slowpath+0x86/0xa0
[ 2845.743742] [<c015041b>] ? trace_hardirqs_off+0xb/0x10
[ 2845.743742] [<c0146384>] ? up+0x14/0x40
[ 2845.743742] [<c012e661>] ? release_console_sem+0x31/0x1e0
[ 2845.743742] [<c046c8ab>] ? _spin_lock_irqsave+0x6b/0x80
[ 2845.743742] [<c015041b>] ? trace_hardirqs_off+0xb/0x10
[ 2845.743742] [<c046c900>] ? _read_lock_irqsave+0x40/0x80
[ 2845.743742] [<c012e7f2>] ? release_console_sem+0x1c2/0x1e0
[ 2845.743742] [<c0146384>] ? up+0x14/0x40
[ 2845.743742] [<c015041b>] ? trace_hardirqs_off+0xb/0x10
[ 2845.743742] [<c046a3d7>] ? __mutex_unlock_slowpath+0x97/0x160
[ 2845.743742] [<c046a563>] ? mutex_trylock+0xb3/0x180
[ 2845.743742] [<c046a4a8>] ? mutex_unlock+0x8/0x10
[ 2845.743742] [<c015b991>] smp_call_function_many+0x151/0x200
[ 2845.743742] [<c010a1a0>] ? stop_this_cpu+0x0/0x40
[ 2845.743742] [<c015ba61>] smp_call_function+0x21/0x30
[ 2845.743742] [<c01137ae>] native_smp_send_stop+0x1e/0x50
[ 2845.743742] [<c012e0f5>] panic+0x55/0x110
[ 2845.743742] [<c01065a8>] oops_end+0xb8/0xc0
[ 2845.743742] [<c010668f>] die+0x4f/0x70
[ 2845.743742] [<c011a8c9>] do_page_fault+0x269/0x610
[ 2845.743742] [<c011a660>] ? do_page_fault+0x0/0x610
[ 2845.743742] [<c046cbaf>] error_code+0x77/0x7c
[ 2845.743742] [<c015515c>] ? __lock_acquire+0x6c/0xa80
[ 2845.743742] [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0
[ 2845.743742] [<c0155be6>] lock_acquire+0x76/0xa0
[ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742] [<c046c885>] _spin_lock_irqsave+0x45/0x80
[ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742] [<c03e1aad>] skb_dequeue+0x1d/0x70
[ 2845.743742] [<c03e1f94>] skb_queue_purge+0x14/0x20
[ 2845.743742] [<f8171f5a>] hci_conn_del+0x10a/0x1c0 [bluetooth]
[ 2845.743742] [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap]
[ 2845.743742] [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth]
[ 2845.743742] [<f8175758>] hci_event_packet+0x5f8/0x31c0 [bluetooth]
[ 2845.743742] [<c03dfe19>] ? sock_def_readable+0x59/0x80
[ 2845.743742] [<c046c14d>] ? _read_unlock+0x1d/0x20
[ 2845.743742] [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth]
[ 2845.743742] [<c015388b>] ? trace_hardirqs_on+0xb/0x10
[ 2845.743742] [<f816fa6a>] hci_rx_task+0x2ba/0x490 [bluetooth]
[ 2845.743742] [<c0133661>] ? tasklet_action+0x31/0xc0
[ 2845.743742] [<c013367c>] tasklet_action+0x4c/0xc0
[ 2845.743742] [<c0132eb7>] __do_softirq+0xa7/0x170
[ 2845.743742] [<c0116dec>] ? ack_apic_level+0x5c/0x1c0
[ 2845.743742] [<c0132fd7>] do_softirq+0x57/0x60
[ 2845.743742] [<c01333dc>] irq_exit+0x7c/0x90
[ 2845.743742] [<c01055bb>] do_IRQ+0x4b/0x90
[ 2845.743742] [<c01333d5>] ? irq_exit+0x75/0x90
[ 2845.743742] [<c010392c>] common_interrupt+0x2c/0x34
[ 2845.743742] [<c010a14f>] ? mwait_idle+0x4f/0x70
[ 2845.743742] [<c0101c05>] cpu_idle+0x65/0xb0
[ 2845.743742] [<c045731e>] rest_init+0x4e/0x60
[ 2845.743742] ---[ end trace 4c985b38f02227a0 ]---
[ 2845.743742] ------------[ cut here ]------------
[ 2845.743742] WARNING: at kernel/smp.c:226 smp_call_function_single+0x8e/0x110()
[ 2845.743742] Hardware name: Dell DM051
[ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev
[ 2845.743742] Pid: 0, comm: swapper Tainted: G D W 2.6.29-rc5-smp #54
[ 2845.743742] Call Trace:
[ 2845.743742] [<c012e076>] warn_slowpath+0x86/0xa0
[ 2845.743742] [<c012e000>] ? warn_slowpath+0x10/0xa0
[ 2845.743742] [<c015041b>] ? trace_hardirqs_off+0xb/0x10
[ 2845.743742] [<c0146384>] ? up+0x14/0x40
[ 2845.743742] [<c012e661>] ? release_console_sem+0x31/0x1e0
[ 2845.743742] [<c046c8ab>] ? _spin_lock_irqsave+0x6b/0x80
[ 2845.743742] [<c015041b>] ? trace_hardirqs_off+0xb/0x10
[ 2845.743742] [<c046c900>] ? _read_lock_irqsave+0x40/0x80
[ 2845.743742] [<c012e7f2>] ? release_console_sem+0x1c2/0x1e0
[ 2845.743742] [<c0146384>] ? up+0x14/0x40
[ 2845.743742] [<c015b7be>] smp_call_function_single+0x8e/0x110
[ 2845.743742] [<c010a1a0>] ? stop_this_cpu+0x0/0x40
[ 2845.743742] [<c026d23f>] ? cpumask_next_and+0x1f/0x40
[ 2845.743742] [<c015b95a>] smp_call_function_many+0x11a/0x200
[ 2845.743742] [<c010a1a0>] ? stop_this_cpu+0x0/0x40
[ 2845.743742] [<c015ba61>] smp_call_function+0x21/0x30
[ 2845.743742] [<c01137ae>] native_smp_send_stop+0x1e/0x50
[ 2845.743742] [<c012e0f5>] panic+0x55/0x110
[ 2845.743742] [<c01065a8>] oops_end+0xb8/0xc0
[ 2845.743742] [<c010668f>] die+0x4f/0x70
[ 2845.743742] [<c011a8c9>] do_page_fault+0x269/0x610
[ 2845.743742] [<c011a660>] ? do_page_fault+0x0/0x610
[ 2845.743742] [<c046cbaf>] error_code+0x77/0x7c
[ 2845.743742] [<c015515c>] ? __lock_acquire+0x6c/0xa80
[ 2845.743742] [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0
[ 2845.743742] [<c0155be6>] lock_acquire+0x76/0xa0
[ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742] [<c046c885>] _spin_lock_irqsave+0x45/0x80
[ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70
[ 2845.743742] [<c03e1aad>] skb_dequeue+0x1d/0x70
[ 2845.743742] [<c03e1f94>] skb_queue_purge+0x14/0x20
[ 2845.743742] [<f8171f5a>] hci_conn_del+0x10a/0x1c0 [bluetooth]
[ 2845.743742] [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap]
[ 2845.743742] [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth]
[ 2845.743742] [<f8175758>] hci_event_packet+0x5f8/0x31c0 [bluetooth]
[ 2845.743742] [<c03dfe19>] ? sock_def_readable+0x59/0x80
[ 2845.743742] [<c046c14d>] ? _read_unlock+0x1d/0x20
[ 2845.743742] [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth]
[ 2845.743742] [<c015388b>] ? trace_hardirqs_on+0xb/0x10
[ 2845.743742] [<f816fa6a>] hci_rx_task+0x2ba/0x490 [bluetooth]
[ 2845.743742] [<c0133661>] ? tasklet_action+0x31/0xc0
[ 2845.743742] [<c013367c>] tasklet_action+0x4c/0xc0
[ 2845.743742] [<c0132eb7>] __do_softirq+0xa7/0x170
[ 2845.743742] [<c0116dec>] ? ack_apic_level+0x5c/0x1c0
[ 2845.743742] [<c0132fd7>] do_softirq+0x57/0x60
[ 2845.743742] [<c01333dc>] irq_exit+0x7c/0x90
[ 2845.743742] [<c01055bb>] do_IRQ+0x4b/0x90
[ 2845.743742] [<c01333d5>] ? irq_exit+0x75/0x90
[ 2845.743742] [<c010392c>] common_interrupt+0x2c/0x34
[ 2845.743742] [<c010a14f>] ? mwait_idle+0x4f/0x70
[ 2845.743742] [<c0101c05>] cpu_idle+0x65/0xb0
[ 2845.743742] [<c045731e>] rest_init+0x4e/0x60
[ 2845.743742] ---[ end trace 4c985b38f02227a1 ]---
[ 2845.743742] Rebooting in 3 seconds..
My logitec bluetooth mouse trying connect to pc, but
pc side reject the connection again and again. then panic happens.
The reason is due to hci_conn_del_sysfs now called in hci_event_packet,
the del work is done in a workqueue, so it's possible done before
skb_queue_purge called.
I move the hci_conn_del_sysfs after skb_queue_purge just as that before
marcel's commit.
Remove the hci_conn_del_sysfs in hci_conn_hash_flush as well due to
hci_conn_del will deal with the work.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 96a3183322cba1a2846771b067c99b9d6f481263 |
|
12-Feb-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Set authentication requirement before requesting it
The authentication requirement got only updated when the security level
increased. This is a wrong behavior. The authentication requirement is
read by the Bluetooth daemon to make proper decisions when handling the
IO capabilities exchange. So set the value that is currently expected by
the higher layers like L2CAP and RFCOMM.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 2950f21acb0f6b8fcd964485c2ebf1e06545ac20 |
|
12-Feb-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Ask upper layers for HCI disconnect reason
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 <marcel@holtmann.org>
|
| 657e17b03c80bec817975984d221bef716f83558 |
|
06-Feb-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Set authentication requirements if not available
When no authentication requirements are selected, but an outgoing or
incoming connection has requested any kind of security enforcement,
then set these authentication requirements.
This ensures that the userspace always gets informed about the
authentication requirements (if available). Only when no security
enforcement has happened, the kernel will signal invalid requirements.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 0684e5f9fb9e3f7e168ab831dfca693bcb44805b |
|
09-Feb-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Use general bonding whenever possible
When receiving incoming connection to specific services, always use
general bonding. This ensures that the link key gets stored and can be
used for further authentications.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| efc7688b557dd1be10eead7399b315efcb1dbc74 |
|
06-Feb-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Add SCO fallback for eSCO connection attempts
When attempting to setup eSCO connections it can happen that some link
manager implementations fail to properly negotiate the eSCO parameters
and thus fail the eSCO setup. Normally the link manager is responsible
for the negotiation of the parameters and actually fallback to SCO if
no agreement can be reached. In cases where the link manager is just too
stupid, then at least try to establish a SCO link if eSCO fails.
For the Bluetooth devices with EDR support this includes handling packet
types of EDR basebands. This is particular tricky since for the EDR the
logic of enabling/disabling one specific packet type is turned around.
This fix contains an extra bitmask to disable eSCO EDR packet when
trying to fallback to a SCO connection.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 8c1b235594fbab9a13240a1dac12ea9fd99b6440 |
|
15-Jan-2009 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Add enhanced security model for Simple Pairing
The current security model is based around the flags AUTH, ENCRYPT and
SECURE. Starting with support for the Bluetooth 2.1 specification this is
no longer sufficient. The different security levels are now defined as
SDP, LOW, MEDIUM and SECURE.
Previously it was possible to set each security independently, but this
actually doesn't make a lot of sense. For Bluetooth the encryption depends
on a previous successful authentication. Also you can only update your
existing link key if you successfully created at least one before. And of
course the update of link keys without having proper encryption in place
is a security issue.
The new security levels from the Bluetooth 2.1 specification are now
used internally. All old settings are mapped to the new values and this
way it ensures that old applications still work. The only limitation
is that it is no longer possible to set authentication without also
enabling encryption. No application should have done this anyway since
this is actually a security issue. Without encryption the integrity of
the authentication can't be guaranteed.
As default for a new L2CAP or RFCOMM connection, the LOW security level
is used. The only exception here are the service discovery sessions on
PSM 1 where SDP level is used. To have similar security strength as with
a Bluetooth 2.0 and before combination key, the MEDIUM level should be
used. This is according to the Bluetooth specification. The MEDIUM level
will not require any kind of man-in-the-middle (MITM) protection. Only
the HIGH security level will require this.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| a418b893a6af11ae73c762ed5b76c1bad6dc19d8 |
|
30-Nov-2008 |
Marcel Holtmann <marcel@holtmann.org> |
Bluetooth: Enable per-module dynamic debug messages
With the introduction of CONFIG_DYNAMIC_PRINTK_DEBUG it is possible to
allow debugging without having to recompile the kernel. This patch turns
all BT_DBG() calls into pr_debug() to support dynamic debug messages.
As a side effect all CONFIG_BT_*_DEBUG statements are now removed and
some broken debug entries have been fixed.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| e7c29cb16c833441fd2160642bb13025f4e7ac70 |
|
09-Sep-2008 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Reject L2CAP connections on an insecure ACL link
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>
|
| 09ab6f4c2376a0fc31abde1e2991513f900ea825 |
|
09-Sep-2008 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Enforce correct authentication requirements
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>
|
| 7d0db0a373195385a2e0b19d1f5e4b186fdcffac |
|
14-Jul-2008 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Use a more unique bus name for connections
When attaching Bluetooth low-level connections to the bus, the bus name
is constructed from the remote address since at that time the connection
handle is not assigned yet. This has worked so far, but also caused a
lot of troubles. It is better to postpone the creation of the sysfs
entry to the time when the connection actually has been established
and then use its connection handle as unique identifier.
This also fixes the case where two different adapters try to connect
to the same remote device.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
| 40be492fe4fab829951681860c2bb26fa1d5fe4a |
|
14-Jul-2008 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Export details about authentication requirements
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>
|
| 769be974d0c7b4fe1a52f9cdaad22259b60953f7 |
|
14-Jul-2008 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Use ACL config stage to retrieve remote features
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>
|
| 41a96212b3b7b3cd59e8e8d33e6dabf0e21d9778 |
|
14-Jul-2008 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Track status of remote Simple Pairing mode
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>
|
| e4e8e37c42bdaaefcb84eeaef0dc1bc3f696f8f6 |
|
14-Jul-2008 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Make use of the default link policy settings
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>
|
| a8746417e864da1ed36dd2432a399fbeb843c2a0 |
|
14-Jul-2008 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Track connection packet type changes
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>
|
| 0cd63c8089f0f6316df1393c3a93bdbc67ab314d |
|
19-Feb-2008 |
Dave Young <hidave.darkstar@gmail.com> |
bluetooth: put hci dev after del conn
Move hci_dev_put to del_conn to avoid hci dev going away before hci conn.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| b24b8a247ff65c01b252025926fe564209fae4fc |
|
24-Jan-2008 |
Pavel Emelyanov <xemul@openvz.org> |
[NET]: Convert init_timer into setup_timer
Many-many code in the kernel initialized the timer->function
and timer->data together with calling init_timer(timer). There
is already a helper for this. Use it for networking code.
The patch is HUGE, but makes the code 130 lines shorter
(98 insertions(+), 228 deletions(-)).
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| 38b7da09cfdb2202f08476d6fb22a47649a177ec |
|
30-Dec-2007 |
Dave Young <hidave.darkstar@gmail.com> |
[BLUETOOTH]: put_device before device_del fix
Because of workqueue delay, the put_device could be called before
device_del, so move it to del_conn.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| b6a0dc822497e1c0b9e8c4add270cc27fce48454 |
|
20-Oct-2007 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Add support for handling simple eSCO links
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>
|
| a9de9248064bfc8eb0a183a6a951a4e7b5ca10a4 |
|
20-Oct-2007 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Switch from OGF+OCF to using only opcodes
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>
|
| 5b7f990927fe87ad3bec762a33c0e72bcbf6841e |
|
11-Jul-2007 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Add basics to better support and handle eSCO links
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>
|
| aca3192cc60d2bf193c2252e45563c32e3117289 |
|
26-Mar-2007 |
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> |
[NET] BLUETOOTH: Use cpu_to_le{16,32}() where appropriate.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| cd354f1ae75e6466a7e31b727faede57a1f89ca5 |
|
14-Feb-2007 |
Tim Schmielau <tim@physik3.uni-rostock.de> |
[PATCH] remove many unneeded #includes of sched.h
After Al Viro (finally) succeeded in removing the sched.h #include in module.h
recently, it makes sense again to remove other superfluous sched.h includes.
There are quite a lot of files which include it but don't actually need
anything defined in there. Presumably these includes were once needed for
macros that used to live in sched.h, but moved to other header files in the
course of cleaning it up.
To ease the pain, this time I did not fiddle with any header files and only
removed #includes from .c-files, which tend to cause less trouble.
Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
configs in arch/arm/configs on arm. I also checked that no new warnings were
introduced by the patch (actually, some warnings are removed that were emitted
by unnecessarily included header files).
Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
| 8e87d14255acffeee36873de226dc25c11b5f46d |
|
09-Feb-2007 |
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> |
[NET] BLUETOOTH: Fix whitespace errors.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| 4c67bc74f016b0d360b8573e18969c0ff7926974 |
|
15-Oct-2006 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Support concurrent connect requests
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>
|
| 6ac59344ef25d5f0ebadb5663cf700d25d2a3886 |
|
26-Sep-2006 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Support create connection cancel command
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>
|
| b219e3ac66183fc9771b94af931fb5fd41d586ec |
|
06-Jul-2006 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Integrate low-level connections into the driver model
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>
|
| 04837f6447c7f3ef114cda1ad761822dedbff8cf |
|
03-Jul-2006 |
Marcel Holtmann <marcel@holtmann.org> |
[Bluetooth] Add automatic sniff mode support
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>
|
| 6ab3d5624e172c553004ecc862bfeac16d9d68b7 |
|
30-Jun-2006 |
Jörn Engel <joern@wohnheim.fh-wedel.de> |
Remove obsolete #include <linux/config.h>
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
|
| 12fe2c588df77d60dfe13b432f95d00f76b8c969 |
|
10-Jan-2006 |
Jesper Juhl <jesper.juhl@gmail.com> |
[NET]: Remove unneeded kmalloc() return value casts
Get rid of needless casting of kmalloc() return value in net/
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| 5523662c4cd585b892811d7bb3e25d9a787e19b3 |
|
26-Apr-2005 |
Al Viro <viro@parcelfarce.linux.theplanet.co.uk> |
[NET]: kill gratitious includes of major.h
A lot of places in there are including major.h for no reason
whatsoever. Removed. And yes, it still builds.
The history of that stuff is often amusing. E.g. for net/core/sock.c
the story looks so, as far as I've been able to reconstruct it: we used to
need major.h in net/socket.c circa 1.1.early. In 1.1.13 that need had
disappeared, along with register_chrdev(SOCKET_MAJOR, "socket", &net_fops)
in sock_init(). Include had not. When 1.2 -> 1.3 reorg of net/* had moved
a lot of stuff from net/socket.c to net/core/sock.c, this crap had followed...
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| b453257f057b834fdf9f4a6ad6133598b79bd982 |
|
26-Apr-2005 |
Al Viro <viro@www.linux.org.uk> |
[PATCH] kill gratitious includes of major.h under net/*
A lot of places in there are including major.h for no reason whatsoever.
Removed. And yes, it still builds.
The history of that stuff is often amusing. E.g. for net/core/sock.c
the story looks so, as far as I've been able to reconstruct it: we used
to need major.h in net/socket.c circa 1.1.early. In 1.1.13 that need
had disappeared, along with register_chrdev(SOCKET_MAJOR, "socket",
&net_fops) in sock_init(). Include had not. When 1.2 -> 1.3 reorg of
net/* had moved a lot of stuff from net/socket.c to net/core/sock.c,
this crap had followed...
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
| 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 |
|
17-Apr-2005 |
Linus Torvalds <torvalds@ppc970.osdl.org> |
Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|