When the reason code in the L2CAP command reject is "invalid CID" there
should be four additional bytes of data in the PDU, namely the source
and destination CIDs (which should be zero if one or both are not
applicable). This patch fixes all occurrences of such errors to return
the right kind of PDU.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Since there is update_scan_rsp_data, it is also better to use the
clear name update_adv_data instead of update_ad.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The scan response data is a better place to store the device name
since it has more space available and is also enforcing privacy.
When the controller is advertising, the connectable setting decides
if ADV_IND or ADV_NONCONN_IND is used. In case of ADV_IND, the
remote side is allowed to request the scan response data. Same as
with BR/EDR where either EIR is used or a remote name request. In
non-connectable mode, the device name is not available since it is
not allowed to request scan response data. Same as in BR/EDR where
the device is non-discoverable and no name requests are answered.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
On controller power on and when enabling LE functionality,
make sure that also the scan response data is correctly set.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The scan response data needs to be stored in HCI device and so
add a buffer for it and also ensure to clear it when resetting
the controller.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Rename the create_ad function into create_adv_data to make it clear
that it is used to create the advertising data. This is important
since later on a function adding the scan response data will be
added.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The return value of mgmt_new_ltk() function is not used and
so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
The return value of mgmt_read_local_oob_data_reply_complete() function
is not used and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
The return value of mgmt_set_local_name_complete() function is
not used and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
The return value of mgmt_set_class_of_dev_complete() function is
not used and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
The return value of mgmt_ssp_enable_complete() function is not
used and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
The return value of mgmt_auth_enable_complete() function is not
used and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
The return value of mgmt_auth_failed() function is not used
and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
The return value of mgmt_pin_code_neg_reply_complete() function is
not used and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
The return value of mgmt_pin_code_reply_complete() function is not
used and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
The return value of mgmt_pin_code_request() function is not used
and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
In this case the replacement by l2cap_chan_ready() doesn't change the code
flow, the same operations will executed plus two others that have no
effect: the use of the parent socket, that a non-oriented channel doesn't
have and the reset of conf_state, which is also fine since the connection
is ready at this point.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The wait_ack code has a heavy dependency on the socket data structures
and, as of now, it won't be worthless change it to use non-socket
structures as the only user of such feature is a socket.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
We need to remove all direct access of struct sock from L2CAP core.
This change is pretty simple and just add a new L2CAP channel callback to
do the work in the L2CAP socket side.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
As part of the work to remove struct sock from l2cap_core.c and make it
more generic we remove in this commit the direct access to sk->sk_sndtimeo
member. This objective of this change is purely remove sk usage from
l2cap_core.c
Now we have a new l2cap ops to get the current value of sk->sndtimeo. A
l2cap_chan_no_get_sndtimeo was added for users of L2CAP that doesn't need
to set a timeout.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
l2cap_state_change_and_error() introduces the ability to update a
l2cap_user with changes in channel's state and error code with just one
call. The main reason for this is to avoid race conditions between and
setting the state and then the error. Otherwise we would need to release
the lock between both operations.
This is another step of an ongoing work to make l2cap_core.c totally
independent from l2cap's struct sock.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Instead of creating an new function pointer to report errors we are just
reusing state_change for that and there is a simple reason for this, one
place in the l2cap_core.c code needs, in a locked sk, set both the sk_state
and sk_err. If we create two different functions for this we would need to
release the lock between the two operation putting the socket in non
desired state.
The change is transparent to the l2cap_core.c code, user that only needs
to set the state won't need any modification.
This is another step of an ongoing work to make l2cap_core.c totally
independent from l2cap's struct sock.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When the discoverable timeout triggers and limited discoverable mode
was used, then the class of device needs to be updated to remove
the limited discoverable bit.
To keep the class of device logic in a central place, expose a new
function mgmt_discoverable_timeout that can be called from the
timeout callback. In case the class of device value needs updating,
it will add the HCI command to the transaction.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The eir_get_length() function is only used from hci_event.c and so
instead of having a public function move it to the location where
it is used.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The eir_append_data() function is only used from mgmt.c and so
instead of having a public function move it to the location where
it is used.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The return value of mgmt_new_link_key() function is not used
and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The limited discoverable mode should be used when a device is only
discoverable for a certain amount of time and after that it returns
back into being non-discoverable.
This adds another option to the set discoverable management command
to clearly distinguish limited discoverable from general discoverable
mode.
While the general discoverable mode can be set with a specific
timeout or as permanent setting, the limited discoverable mode
requires a timeout. The timeout is flexible and the kernel will
not enforce any specific limitations. That GAP part of this is
required by userspace to enforce according to the Bluetooth core
specification.
Devices in limited discoverable mode can still be found by the
general discovery procedure. It is mandatory that a device sets
both GIAC and LIAC when entering limited discoverable mode.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When only the discoverable timeout gets updated, just cancel the current
timeout, store the new timeout value. If the new timeout is valid, then
arm the discoverable timeout again.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The discoverable timeout is currently armed from hci_event.c and causes
some side effects when using HCI commands instead of the management
interface. To make this clear, only arm the discoverable timeout from
the management command complete handler.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When the discoverable mode gets changed, ensure that the class of
device value has the correct limited discoverable bit value set.
Since the class of device HCI command will only be send to the
controller when the value changes, it is safe to just always
trigger the update.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The return value of mgmt_write_scan_failed() function is not used
and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The return value of mgmt_connectable() function is not used
and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The return value of mgmt_discoverable() function is not used
and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Add a new flag that can be set when in limited discoverable mode. This
flag will cause the limited discoverable bit in the class of device
value to bet set.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Magically updating the advertising data when some random command enables
advertising in the controller is not really a good idea. It also caused
a bit of complicated code with the exported hci_udpate_ad function that
is shared from many places.
This patch consolidates the advertising data update into the management
core. It also makes sure that when powering on with LE enabled or later
on enabling LE the controller has a good default for advertising data.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When the discoverable timeout triggers and it is time to turn inquiry
scan back off, use the HCI request framework to do it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
There is a minor coding style violation and so just fix it. No actual
logic has changed.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Read the current IAC LAP values when initializing the controller. The
values are not used, but it is good to have them in the trace files
for debugging purposes.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
When initializing a controller make sure to read out the number of
supported IAC and store its result. This value is needed to determine
if limited discoverable for BR/EDR can be configured or not.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
The scan window parameter for connection establishment and passive
scanning needs to be smaller or equal than the scan interval.
Instead of waiting for a controller to reject these values later on,
just reject them right away.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
If a socket was bound to an address type other than BR/EDR (such as LE)
we should reject trying to connect it to a BR/EDR address. The same
applies for binding to BR/EDR and trying to connect to non-BR/EDR.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
We need to verify that the bdaddr type passed to connect() and bind() is
within the set of valid values. If it is not we need to cleanly fail
with EINVAL.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch converts Set Discoverable to use an asynchronous request
along with its own completion callback. This is necessary for splitting
raw HCI socket use cases from mgmt, as well as for enabling the hooking
up of Advertising parameters together with the HCI_DISCOVERABLE flag
(coming in later patches).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Now that the connectable setting is also applicable for the LE side it's
possible that the HCI_CONNECTABLE flag is already set when changing the
BR/EDR setting from false to true while the controller is powered. In
this situation we need to update the BR/EDR scan mode to reflect the
setting. Additionally, since HCI_CONNECTABLE also applies to LE we must
not clear the HCI_CONNECTABLE flag when disabling bredr.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The set_bredr_scan() function will soon be needed by the set_bredr()
function, so move it to a new location to avoid having to add a forward
declaration.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch updates the Set Connectable Management command to also update
the LE advertising type to either connectable or non-connectable
advertising. An extra helper function is needed for getting the right
advertising type since we can not only rely on the HCI_CONNECTABLE flag
but must also check for a pending Set Connectable command (in which case
the flag does not yet have its final value).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
We need to ensure that the advertising data is up-to-date whenever
advertising is enabled, but when disabling advertising we do not need to
worry about it (since it will eventually get fixed as soon as
advertising is enabled again). This patch fixes this in the command
complete callback for set_adv_enable.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
These functions will soon be used by set_connectable() so move them to a
location in mgmt.c that doesn't require forward declarations.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If the HCI commands related to the Set Connectable command fail we will
get a non-zero status in the request completion callback. In such a case
we must respond with the appropriate command status message to user space.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch moves the responsibility of setting/clearing the
HCI_CONNECTABLE flag to the request completion callback of the Set
Connectable command. This will allow us to cleanly add support for LE
Advertising hooks in later patches.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch moves all the decisions of which HCI commands to send (or not
to send) to the code between hci_req_init() and hci_req_run() this
allows us to further extend the request with further commands but still
keep the same logic of handling whether to return a direct mgmt response
in the case that no HCI commands were sent.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Clearing the BT_SK_SUSPEND socket flag from the L2CAP core is causing
a dependency on the socket. So intead of doing that, use a channel
callback into the socket handling to resume.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The L2CAP core should not look into the socket flags to figure out the
setting of defer setup. So introduce a L2CAP channel flag that mirrors
the socket flag.
Since the defer setup option is only set in one place this becomes a
really easy thing to do.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The exposed socket information do not contain source or destination
addresses. So adjust the header accordingly.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
There have been a lot of changes in the core Bluetooth handling
lately. So it is a good idea to increase the module version.
The module version is not used anywhere, but it makes debugging
a little bit simpler if versions can be distinguished.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The L2CAP connectionless channels use SOCK_DGRAM and recvmsg() and need
to receive the remote BD_ADDR and PSM information via msg_name from
the recvmsg() system call.
So in case the L2CAP socket is for connectionless channels, provide
a msg_name callback that can update the data. Also store the remote
BD_ADDR and PSM in the skb so it can be extracted later on.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This allows to add a per socket msg_name callback that can be used
for updating the msg_name information for recvmsg() system calls.
This feature is used by another patch to support address information
on L2CAP connectionless channels.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
There are few places where it makes sense to use l2cap_pi(sk) directly
instead of assigning it to temporary structure.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Every socket protocol now stores its own address information. So
just remove the generic src and dst fields since they are no longer
needed.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The address information of RFCOMM sockets should be stored in its
own socket structure. Trying to generalize them is not helpful since
different transports have different address types.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The address information of SCO sockets should be stored in its own
socket structure. Trying to generalize them is not helpful since
different transports have different address types.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Instead of storing a pointer to the addresses for the HCI device
and HCI connection, use them directly. With the recent changes
to address tracking of HCI connections, this becomes simple.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The L2CAP socket structure does not contain the address information
anymore. They need to be accessed through the L2CAP channel.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The L2CAP socket structure does not contain the address information
anymore. They need to be accessed through the L2CAP channel.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The L2CAP socket structure does not contain the address information
anymore. They need to be accessed through the L2CAP channel.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The L2CAP socket structure does not contain the address information
anymore. They need to be accessed through the L2CAP channel.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The L2CAP sockets can use BR/EDR public, LE public and LE random
addresses for various combinations of source and destination
devices. So make sure that getsockname(), getpeername() and
accept() return the correct address type.
For this the address type of the source and destination is stored
with the L2CAP channel information. The stored address type is
not the one specific for the HCI protocol. It is the address
type used for the L2CAP sockets and the management interface.
The underlying HCI connections store the HCI address type. If
needed, it gets converted to the socket address type.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
With the effort of abstracting the L2CAP socket from the underlying
L2CAP channel it is important to store the source and destination
address information directly in the L2CAP channel structure.
Direct access to the HCI connection address information is not
possible since they might not be avaiable at L2CAP channel
creation time. The address information will be updated when
the underlying BR/EDR or LE connection status changes.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When having LE connections, the source address is not always the
public address of the controller. So update the socket address
based on the actual used source address of the HCI connection.
This also remove the pointless source address pointer and adds
a proper lock around the socket structure.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The SMP source code has a few coding style violations. Fix them up
all at once. No actual code has changed.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The smp_c1() so far always assumed public addresses as input for its
operation. However it should provide actually the source address type
of the actual connection.
Finally the source address type is tracked in hci_conn->src_type and
so use that one as input.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The source address is now stored in hci_conn->src and so use that
one for L2CAP functions.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The source address is now stored in hci_conn->src and so use that
one for SMP functions.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The incoming LE connections do not have a proper source address and
address type set. The connection needs to be set with the same values
as used for advertising parameters.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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>
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>
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>
The l2cap_conn->src and l2cap_conn->dst addresses are just a pointers
to hci_conn structure. Use hci_conn->hdev->bdaddr and hci_conn->dst
directly instead.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The l2cap_conn->src and l2cap_conn->dst addresses are just a pointer
to hci_conn->hdev->bdaddr and hci_conn->dst structures. Use the data
provided by hci_conn directly. This is done for hci_conn->dst_type
already anyway and with this change it makes it a lot clearer were
the address information comes from.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The l2cap_conn->dst address is just a pointer into the hci_conn->dst
structure. Use hci_conn->dst directly instead.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The unicast connectionless data reception feature is actually support
and has been supported all along. Mark it as supported in the L2CAP
features bitmask.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The implementation actually supports the L2CAP connectionless data
channel. So set it as supported in the fixed channels bitmask.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The PSM 0x0021 is dedicated to the 3D profile and has permission to
use security mode 4 level 0 for L2CAP connectionless unicast data
transfers.
When establishing a L2CAP connectionless channel on PSM 0x0021, it
will no longer force Secure Simple Pairing.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The exception for certain PSM channels when it comes to security
mode 4 level 0 should only be checked when actually a connection
oriented channel is established.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The put_unaligned() for setting the PSM is missing the (__le16 *)
cast. Without this, the PSM information transmitted over the air
are bogus.
In addition, print the used PSM value in the debug message so this
becomes easier to debug in the future.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The 1st generation of BlueFRITZ! devices from AVM Berlin pretend
to be HCI version 1.2 controllers, but they are not. They are simple
Bluetooth 1.1 devices.
Since this company never created any newer controllers, it is safe
to use the manufacturer ID instead of an USB quirk.
< HCI Command: Read Page Scan Activity (0x03|0x001b) plen 0
> HCI Event: Command Complete (0x0e) plen 8
Read Page Scan Activity (0x03|0x001b) ncmd 1
Status: Success (0x00)
Interval: 1280.000 msec (0x0800)
Window: 21.250 msec (0x0022)
< HCI Command: Read Page Scan Type (0x03|0x0046) plen 0
> HCI Event: Command Status (0x0f) plen 4
Read Page Scan Type (0x03|0x0046) ncmd 1
Status: Unknown HCI Command (0x01)
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When adding support for MGMT_OP_SET_SCAN_PARAMS command the addition
to the supported commands list has been forgotten. This is needed
for userspace to detect if the command is supported or not.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
It is not allowed to enable high speed support when Secure Simple
Pairing is not available or disabled.
However the support for high speed gets advertised on a controller
that does not even support Secure Simple Pairing. Since there is
no way to enable high speed support on such a controller, do not
even advertise its support.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Really early versions of the Bluetooth specification were unclear
with the behavior of HCI Reset for USB devices. They assumed that
also an USB reset needs to be issued. Later Bluetooth specifications
cleared this out and it is safe to call HCI Reset without affecting
the transport.
For old devices that misbehave, the HCI_QUIRK_RESET_ON_CLOSE quirk
was introduced to postpone the HCI Reset until the device was no
longer in use.
One of these devices is the Digianswer BPA-105 Bluetooth Protocol
Analyzer. The only problem now is that with the quirk set, the
HCI Reset is also executed at the end of the setup phase. So the
controller gets configured and then it disconnects from the USB
bus, connects again, gets configured and of course disconnects
again. This game goes on forever.
For devices that need HCI_QUIRK_RESET_ON_CLOSE it is important
that the HCI Reset is not executed after the setup phase. In
specific when HCI_AUTO_OFF is set, do not call HCI Reset when
closing the device.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The scan interval and window parameters are used for LE passive
background scanning and connection establishment. This allows
userspace to change the values.
These two values should be kept in sync with whatever is used for
the scan parameters service on remote devices. And it puts the
controlling daemon (for example bluetoothd) in charge of setting
the values.
Main use case would be to switch between two sets of values. One
for foreground applications and one for background applications.
At this moment, the values are only used for manual connection
establishment, but soon that should be extended to background
scanning and automatic connection establishment.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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>
Instead of masking hdev inside the skb->dev parameter, hand it
directly to the driver as a parameter to hdev->send. This makes
the driver interface more clear and simpler.
This patch fixes all drivers to accept and handle the new parameter
of hdev->send callback. Special care has been taken for bpa10x
and btusb drivers that require having skb->dev set to hdev for
the URB transmit complete handlers.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
To avoid casting skb->dev into hdev, just let the drivers provide
the hdev directly when calling hci_recv_frame() function.
This patch also fixes up all drivers to provide the hdev.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The return value of hci_send_frame() is never checked. So just make
this function void and print an error when the hdev->send driver
callback returns a negative value.
Having the error printed is actually an improvement over the
current situation where any driver error just gets ignored.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The hdev parameter of hci_send_frame must be always valid. If the hdev
is not valid, it would not even make it to this stage. The callers
will have already accessed hdev at that point many times.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The assignement of skb->dev is done all over the place. So it makes it
hard to eventually get rid of it. Move it all in one central place so
it gets assigned right before calling hdev->send driver callback.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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>
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>
The amp.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>
Since there is no use of hdev->ioctl by any Bluetooth driver since
ever, so just lets remove it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The legacy ioctls for device specific commands including inquiry are
not support by AMP controllers. So just reject them right away instead
of trying to send the HCI command and wait for failure from the
actual hardware.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When checking for the current number of LE connections, use
hci_conn_num() function instead of a full blown lookup within
the connection hash or direct access of the counters.
In the case of re-enabling advertising, it is more useful to
check for any connection attempt or existing connection.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The function declaration goes over 80 characters, so break it down.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When the HCI_SETUP flag is set the controller has not yet been announced
over mgmt and therefore doesn't exist from that perspective. If we
nevertheless get a mgmt command for it we should respond with the
appropriate INVALID_INDEX error.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The l2cap_recv_frame function is expected to take ownership and
eventually free the skb passed to it. We need to ensure that the
conn->rx_skb pointer is no longer reachable when calling
l2cap_recv_frame so that no other function, such as l2cap_conn_del, may
think that it can free conn->rx_skb.
An actual situation when this can happen is when smp_sig_channel (called
from l2cap_recv_frame) fails and l2cap_conn_del gets called as a
consequence. The l2cap_conn_del function would then try to free
conn->rx_skb, but as the same skb was just passed to smp_sig_channel and
freed we get a double-free.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The support for Bluetooth High Speed can only be enabled on controllers
where also Secure Simple Pairing has been enabled. Trying to enable
high speed when SSP is disabled will result into an error. Disabling
SSP will at the same time disable high speed as well.
It is required to enforce this dependency on SSP since high speed
support is only defined for authenticated, unauthenticated and
debug link keys. These link key types require SSP.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The variable val in the set_ssp() function of the management interface
is not needed. Just use cp->val directly since its input values have
already been validated.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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>
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>
We only (re)enable advertising when LE is disconnected. Trying to enable
advertising using mgmt_set_advertising while connected should simply
change the flag but not do anything else (until the connection gets
dropped). This patch fixes this by making an LE connection lookup to
determine whether there are any connected devices or not.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Sparse points out three places where variables are shadowed,
rename two of the variables and remove the duplicate third.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When initializing an AMP controller, read its current flow control
mode so that the correct value is used.
The AMP controller defaults to block based flow control and this
extra command is just to double check.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When initializing an AMP controller, read its current known location
data so that it can be analyzed later on.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The commands for reading supported features and commands are both
supported by AMP controllers. Issue them during controller init
phase so their values are known.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Within the AMP discover response, list powered down AMP controllers
as powered down. No point in trying to make them look any different.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The management interface only operates on BR/EDR controllers. The check
for the power down notification is a bit intermixed with the check if
controller auto power off is active. Since there are more than just
BR/EDR controllers supported, make this check explicit since the auto
power off check also applies to AMP controllers and it has to happen
in this exact order. Otherwise the bit will not be cleared.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Even AMP controllers should be powered off after the setup phase. It
is not a good idea to keep AMP controllers powered on all the time
if they are not in use.
Power on of the AMP controller can either be done manually via
command line commands or directly via A2MP. Especially since there
is an indication in A2MP for powered down controllers that can
be activated.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The return value of mgmt_discovering() function is not used
and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The return value of mgmt_remote_name() function is not used
and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The return value of mgmt_device_found() function is not used
and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The return value of mgmt_device_disconnected() function is not used
and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The return value of mgmt_device_connected() function is not used
and so just change it to return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The return value of mgmt_connect_failed() function is not used
so change it to just return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The return value of mgmt_disconnect_failed() function is not used
so change it to just return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The return value of mgmt_set_powered_failed() function is never used
and so make the function just return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The return value from mgmt_index_added() and mgmt_index_removed()
functions is never used. So do not pretend that returning an error
would actually be handled and just make both functions return void.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
In case the current value of pairable is already configured, do not
send a new settings event indicating that something has changed while
in reality everything is the same.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The helper function mgmt_valid_hdev() is more obfuscating the code
then it makes it easier to read. So intead of this helper, use the
direct check for BR/EDR device type.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The mgmt_new_settings() function was only needed to handle the
error case when re-enabling advertising failed. Since that is
now handled internally inside the management core, this function
is not needed anymore. So just remove it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When the all LE connections have been disconneted, then it is up to
the host to re-enable advertising at that point. To ensure that the
correct advertising parameters are used, force the usage of the
common helper to enable advertising.
The change just moves the manual enabling of advertising from the
event handler into the management core so that the helper can
be actually shared.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The LE advertising parameters can only be modified when advertising
is disabled. So before enabling it, make sure the controller has all
the right parameters.
Right now all default values are used and thus this does no change
any existing behavior. One minor exception is that in case of single
mode LE-only controllers without a public address, now the random
address is used for advertising.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The tasks of enabling and disabling advertising are required in many
cases. So refactor the actual HCI operations into two common helpers
to make the code simpler.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This is not a functional change, just change the code to make it easy
to understand that advertising gets disabled before LE support will
be turned off.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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>
When counting the number for AMP controllers, a positive check is
used. To be consistent, use the same check when actually adding
the data for the AMP contollers.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The BR/EDR and LE setup procedures apply only to BR/EDR device types
and so check for that explicitly. Checking that it is not an AMP
controller is dangerous in case there will be ever a third device
type.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
In case of a single mode LE-only controller it is possible that no
public address is used. These type of controllers require a random
address to be configured.
Without a configured static random address, such a controller is
not functional. So reject powering on the controller in this case
until it gets configured with a random address.
The controller setup stage is still run since it is the only way
to determinate if a public address is available or not. So it is
similar on how RFKILL gets handled during initial setup of the
controller.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Within the AMP discover response, all controllers that are not the
primary BR/EDR controller are valid.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The check if a L2CAP connection is AMP capable was a little bit
complicated. This changes the code to make it simpler and more
readable.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The hci_amp_capable() function has only a single user inside the L2CAP
core. Instead of exporting the function, place it next to its user.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The number of controllers for the AMP discover response has already
been calculated. And since the hci_dev_list lock is held, it can not
change. So there is no need for any extra checks.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The inline function for BR/EDR controller AMP discover response
info is rather useless. Just include the code into the function
that builds the whole response.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The AMP controller status constants need to be actually used to avoid
crypted hardcoded numbers.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The special AMP controller id 0 is reserved for the BR/EDR controller
that has the main link. It is a fixed value and so use a constant for
this throughout the code to make it more visible when the handling is
for the BR/EDR channel or when it is for the AMP channel.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
There are two defined HCI device types. One is for BR/EDR controllers
and the other is for AMP controllers. The HCI device type is not the
same as the AMP controller type. It just happens that currently the
defined types match, but that is not guaranteed.
Split the usage of AMP controller type into its own domain so that
it is possible to separate between BR/EDR controllers, 802.11 AMP
controllers and any other AMP technology that might be defined in
the future.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The list of controllers can be counted ahead of time and inline
inside the AMP discover handling. There is no need to export such
a function at all.
In addition just count the AMP controller and only allocated space
for a single mandatory BR/EDR controller. No need to allocate more
space than needed.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The AMP discover response should list exactly one BR/EDR controller
and ignore all other BR/EDR controller.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
LE controllers will automatically disable advertising whenever they
accept a new connection. In order not to fall out of sync with the
advertising setting we need to re-enable advertising whenever the last
LE connection drops. A failure to re-enable advertising should cause the
setting to be disabled, so this patch also calls mgmt_new_settings()
when this happens.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
A function is needed so that the HCI event processing can ask the mgmt
code to emit a new settings event. This is necessary e.g. when the event
processing does updates to mgmt related states without any dependency of
actual mgmt commands.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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>
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>
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>
The Bluetooth specification makes it clear that only one command
should be present in the L2CAP LE signalling packet. So tighten
the checks here and restrict it to exactly one command.
This is different from L2CAP BR/EDR signalling where multiple
commands can be part of the same packet.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When SMP packets are received, make sure they contain at least 1 byte
header for the opcode. If not, drop the packet and disconnect the link.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The ATT fixed channel is only valid when using LE connections. On
BR/EDR it is required to go through L2CAP connection oriented
channel for ATT.
Drop ATT packets when they are received on a BR/EDR connection.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When receiving connectionless packets on a LE connection, just drop
the packet. There is no concept of connectionless channels for LE.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When receiving SMP packets on a BR/EDR connection, then just drop
the packet and do not try to process it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The L2CAP raw sockets are only used for BR/EDR signalling. Packets
on LE links should not be forwarded there.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The switch statement for the various L2CAP fixed channel handlers
is not really ordered.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Changing the device class when BR/EDR is disabled has no visible
effect for remote devices. However to simplify the logic allow it
as long as the controller supports BR/EDR operations.
If it is not allowed, then the overall logic becomes rather
complicated since the class of device values would need clearing
or restoring when BR/EDR setting changes.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Loading long term keys into a BR/EDR only controller make no sense.
The kernel would never use any of these keys. So instead of allowing
userspace to waste memory, reject such operation with a not supported
error message.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Loading link keys into a LE only controller make no sense. The kernel
would never use any of these keys. So instead of allowing userspace
to waste memory, reject such operation with a not supported error
message.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Setting the static address does not depend on LE beeing enabled. It
only depends on a controller with LE support.
When depending on LE enabled this command becomes really complicated
since in case LE gets disabled, it would be required to clear the
static address and also its random address representation inside
the controller. With future support for private addresses such
complex setup should be avoided.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Only when BR/EDR is supported and enabled, allow changing of the SSP
setting. Just checking if the hardware supports SSP is not enough
since it might be the case that BR/EDR is disabled.
In the case that BR/EDR is disabled, but SSP supported by the
controller the not supported error message is now returned.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The wrong type of L2CAP signalling packets on the wrong type of
either BR/EDR or LE links need to be dropped. When that happens
the packet is dropped, but the memory not freed. So actually
free the memory as well.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
This patch increments the management interface revision due to the
various fixes, improvements and other changes that have gone in
lately.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
We shouldn't include the simultaneous LE & BR/EDR flags in the LE
advertising data if BR/EDR is disabled on a dual-mode controller. This
patch fixes this issue and ensures that the create_ad function generates
the correct flags when BR/EDR is disabled.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The REJECTED management response should mainly be used when the adapter
is in a state where we cannot accept some command or a specific
parameter value. The NOT_SUPPORTED response in turn means that the
adapter really cannot support the command or parameter value.
This patch fixes this distinction and adds two helper functions to
easily get the appropriate LE or BR/EDR related status response.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
On dual-mode BR/EDR/LE and LE only controllers it is possible
to configure a random address. There are two types or random
addresses, one is static and the other private. Since the
random private addresses require special privacy feature to
be supported, the configuration of these two are kept separate.
This command allows for setting the static random address. It is
only supported on controllers with LE support. The static random
address is suppose to be valid for the lifetime of the controller
or at least until the next power cycle. To ensure such behavior,
setting of the address is limited to when the controller is
powered off.
The special BDADDR_ANY address (00:00:00:00:00:00) can be used to
disable the static address. This is also the default value.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Disabling the high speed setting when the controller is powered on has
too many side effects that are not taken care of. And in general it
is not an useful operation anyway. So just make such a command fail
with a rejection error message.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This patch introduces a new mgmt command for enabling/disabling BR/EDR
functionality. This can be convenient when one wants to make a dual-mode
controller behave like a single-mode one. The command is only available
for dual-mode controllers and requires that LE is enabled before using
it. The BR/EDR setting can be enabled at any point, however disabling it
requires the controller to be powered off (otherwise a "rejected"
response will be sent).
Disabling the BR/EDR setting will automatically disable all other BR/EDR
related settings.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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>
When hci_sock.c calls hci_dev_open it needs to ensure that there isn't
pending work in progress, such as that which is scheduled for the
initial setup procedure or the one for automatically powering off after
the setup procedure. This adds the necessary calls to ensure that any
previously scheduled work is completed before attempting to call
hci_dev_do_open.
This patch fixes a race with old user space versions where we might
receive a HCIDEVUP ioctl before the setup procedure has been completed.
When that happens the setup procedures callback may fail early and leave
the device in an inconsistent state, causing e.g. the setup callback to
be (incorrectly) called more than once.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The requirements of an external call to hci_dev_open from hci_sock.c are
different to that from within hci_core.c. In the former case we want to
flush any pending work in hdev->req_workqueue whereas in the latter we
don't (since there we are already calling from within the workqueue
itself). This patch does the necessary refactoring to a separate
hci_dev_do_open function (analogous to hci_dev_do_close) but does not
yet introduce the synchronizations relating to the workqueue usage.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Bluetooth protocol and hardware is pretty much all little endian
and so when running sparse via "make C=2" for example, enable the
endian checks by default.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The HCI User Channel operation is an admin operation that puts the
device into promiscuous mode for single use. It is more suitable
to require CAP_NET_ADMIN than CAP_NET_RAW.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When enabling or disabling high speed setting it is required to send
a new settings event to inform other management interface users about
the changed settings.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Hiding the Bluetooth high speed support behind a module parameter is
not really useful. This can be enabled and disabled at runtime via
the management interface. This also has the advantage that this can
now be changed per controller and not just global.
This patch removes the module parameter and exposes the high speed
setting of the management interface to all controllers.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The controller type is limited to BR/EDR/LE and AMP controllers. This
can be easily encoded with just 2 bits and still leave enough room
for future controller types.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This patch adds a new mgmt command for enabling and disabling
LE advertising. The command depends on the LE setting being enabled
first and will return a "rejected" response otherwise. The patch also
adds safeguards so that there will ever only be one set_le or
set_advertising command pending per adapter.
The response handling and new_settings event sending is done in an
asynchronous request callback, meaning raw HCI access from user space to
enable advertising (e.g. hciconfig leadv) will not trigger the
new_settings event. This is intentional since trying to support mixed
raw HCI and mgmt access would mean adding extra state tracking or new
helper functions, essentially negating the benefit of using the
asynchronous request framework. The HCI_LE_ENABLED and HCI_LE_PERIPHERAL
flags however are updated correctly even with raw HCI access so this
will not completely break subsequent access over mgmt.
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>
This patch adds a new mgmt setting for LE advertising and hooks up the
necessary places in the mgmt code to operate on the HCI_LE_PERIPHERAL
flag (which corresponds to this setting). This patch does not yet add
any new command for enabling the setting - that is left for a subsequent
patch.
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>
This patch updates the code to use an asynchronous request for handling
the enabling and disabling of LE support. This refactoring is necessary
as a preparation for adding advertising support, since when LE is
disabled we should also disable advertising, and the cleanest way to do
this is to perform the two respective HCI commands in the same
asynchronous request.
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>
The settings_rsp and cmd_status_rsp functions can be useful for all mgmt
command handlers when asynchronous request callbacks are used. They will
e.g. be used by subsequent patches to change set_le to use an async
request as well as a new set_advertising command. Therefore, move them
higher up in the mgmt.c file to avoid unnecessary forward declarations
or mixing this trivial change with other patches.
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>
We should return a "busy" error always when there is another
mgmt_set_powered operation in progress. Previously when powering on
while the auto off timer was still set the code could have let two or
more pending power on commands to be queued. This patch fixes the issue
by moving the check for duplicate commands to an earlier point in the
set_powered handler.
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>
This patch cleans up the locking login in l2cap_sock_recvmsg by pairing
up each lock_sock call with a release_sock call. The function already
has a "done" label that handles releasing the socket and returning from
the function so the fix is rather simple.
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>
The bt_sock_wait_state requires the sk lock to be held (through
lock_sock) so document it clearly in the code.
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>
Convert 0 to false and 1 to true when assigning values to bool
variables. Inspired by commit 3db1cd5c05.
The simplified semantic patch that find this problem is as
follows (http://coccinelle.lip6.fr/):
@@
bool b;
@@
(
-b = 0
+b = false
|
-b = 1
+b = true
)
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
When the dlc is closed, rfcomm_dev_state_change() tries to release the
port in the case it cannot get a reference to the tty. However this is
racy and not even needed.
Infact as Peter Hurley points out:
1. Only consider dlcs that are 'stolen' from a connected socket, ie.
reused. Allocated dlcs cannot have been closed prior to port
activate and so for these dlcs a tty reference will always be avail
in rfcomm_dev_state_change() -- except for the conditions covered by
#2b below.
2. If a tty was at some point previously created for this rfcomm, then
either
(a) the tty reference is still avail, so rfcomm_dev_state_change()
will perform a hangup. So nothing to do, or,
(b) the tty reference is no longer avail, and the tty_port will be
destroyed by the last tty_port_put() in rfcomm_tty_cleanup.
Again, no action required.
3. Prior to obtaining the dlc lock in rfcomm_dev_add(),
rfcomm_dev_state_change() will not 'see' a rfcomm_dev so nothing to
do here.
4. After releasing the dlc lock in rfcomm_dev_add(),
rfcomm_dev_state_change() will 'see' an incomplete rfcomm_dev if a
tty reference could not be obtained. Again, the best thing to do here
is nothing. Any future attempted open() will block on
rfcomm_dev_carrier_raised(). The unconnected device will exist until
released by ioctl(RFCOMMRELEASEDEV).
The patch removes the aforementioned code and uses the
tty_port_tty_hangup() helper to hangup the tty.
Signed-off-by: Gianluca Anzolin <gianluca@sottospazio.it>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
For those controller that support the HCI_Set_Event_Mask_Page_2 command
we should include it in the init sequence. This patch implements sending
of the command and enables the events in it based on supported features
(currently only CSB is checked).
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>
This patch adds support for reading the synchronization train parameters
for controllers that support the feature. Since the feature is
detectable through the local features page 2, which is retreived only in
stage 3 of the HCI init sequence, there is no other option than to add a
fourth stage to the init sequence.
For now the patch doesn't yet add storing of the parameters, but it is
nevertheless convenient to have around to see what kind of parameters
various controllers use by default (analyzable e.g. with the btmon user
space tool).
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>
In the case of blocking sockets we should not proceed with sendmsg() if
the socket has the BT_SK_SUSPEND flag set. So far the code was only
ensuring that POLLOUT doesn't get set for non-blocking sockets using
poll() but there was no code in place to ensure that blocking sockets do
the right thing when writing to them.
This patch adds a new bt_sock_wait_ready helper function to sleep in the
sendmsg call if the BT_SK_SUSPEND flag is set, and wake up as soon as it
is unset. It also updates the L2CAP and RFCOMM sendmsg callbacks to take
advantage of this new helper function.
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>
When we have an LE link we should not respond to any data on the BR/EDR
L2CAP signaling channel (0x0001) and vice-versa when we have a BR/EDR
link we should not respond to LE L2CAP (CID 0x0005) signaling commands.
This patch fixes this issue by checking for a valid link type and
ignores data if it is wrong.
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>
When L2CAP packets return a non-zero error and the value is passed
onwards by l2cap_bredr_sig_cmd this will trigger a command reject packet
to be sent. However, the core specification (page 1416 in core 4.0) says
the following: "Command Reject packets should not be sent in response to
an identified Response packet.".
This patch ensures that a command reject packet is not sent for any
identified response packet by ignoring the error return value from the
response handler functions.
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>
There are several possible reason codes that can be sent in the command
reject L2CAP packet. Before this patch the code has used a hard-coded
single response code ("command not understood"). This patch adds a
helper function to map the return value of an L2CAP handler function to
the correct command reject reason.
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>
If we receive an L2CAP Disconnect Request for an unknown CID we should
not just silently drop it but reply with a proper Command Reject
response. This patch fixes this by ensuring that the disconnect handler
returns a proper error instead of 0 and will cause the function caller
to send the right response.
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>
The EFAULT error should only be used for memory address related errors
and ENOENT might be needed for other purposes than invalid CID errors.
This patch fixes the l2cap_config_req, l2cap_connect_create_rsp and
l2cap_create_channel_req handlers to use the unique EBADSLT error to
indicate failed lookups on a given CID.
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>
When an L2CAP request handler returns non-zero the calling code will
send a command reject response. The l2cap_create_chan_req function will
in some cases send its own response but then still return a -EFAULT
error which would cause two responses to be sent. This patch fixes this
by making the function return 0 after sending its own response.
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>
We need to let the setup stage complete cleanly even when the HCI device
is rfkilled. Otherwise the HCI device will stay in an undefined state
and never get notified to user space through mgmt (even when it gets
unblocked through rfkill).
This patch makes sure that hci_dev_open() can be called in the HCI_SETUP
stage, that blocking the device doesn't abort the setup stage, and that
the device gets proper powered down as soon as the setup stage completes
in case it was blocked meanwhile.
The bug that this patch fixed can be very easily reproduced using e.g.
the rfkill command line too. By running "rfkill block all" before
inserting a Bluetooth dongle the resulting HCI device goes into a state
where it is never announced over mgmt, not even when "rfkill unblock all"
is run.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Johan Hedberg