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>

Add constants for ADV_IND, ADV_DIRECT_IND, ADV_SCAN_IND and
ADV_NONCONN_IND advertising types.
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>

Add the basic HCI structure for building the LE advertising parameters
command.
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>

Add the constants for BR/EDR and 802.11 AMP controller types.
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>

The Slave Page Response Timeout event indicates to the Host that a
slave page response timeout has occurred in the BR/EDR Controller.

The Core Spec Addendum 4 adds this command in part B Connectionless
Slave Broadcast.

Bluetooth Core Specification Addendum 4 - Page 110

"7.7.72 Slave Page Response Timeout Event [New Section]
...
Note: this event will be generated if the slave BR/EDR Controller
responds to a page but does not receive the master FHS packet
(see Baseband, Section 8.3.3) within pagerespTO.

Event Parameters: NONE"
Signed-off-by: Dohyun Pyun <dh79.pyun@samsung.com>
Signed-off-by: C S Bhargava <cs.bhargava@samsung.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>