The field is not a boolean, it is actually a field for a key type. So
name it properly.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The LTK authenticated parameter is the key type of the LTK and similar
to link keys there is no need to check the currently supported values.
For possible future improvements, the kernel will only use key types
it knows about and just ignore all the other ones.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When encryption for LE links has been enabled, it will always be use
AES-CCM encryption. In case of BR/EDR Secure Connections, the link
will also use AES-CCM encryption. In both cases track the AES-CCM
status in the connection flags.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The function already has an unlock label which means the one extra level
on indentation is not useful and just makes the code more complex. So
remove it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Since the use of debug keys can now be identified from the current
settings information, this debugfs entry is no longer necessary.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Originally allowing the use of debug keys was done via the Load Link
Keys management command. However this is BR/EDR specific and to be
flexible and allow extending this to LE as well, make this an independent
command.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When the controller has been enabled to allow usage of debug keys, then
clearly identify that in the current settings information.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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>
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>
If LTK distribution happens in both directions we will have two LTKs for
the same remote device: one which is used when we're connecting as
master and another when we're connecting as slave. When looking up LTKs
from the locally stored list we shouldn't blindly return the first match
but also consider which type of key is in question. If we do not do this
we may end up selecting an incorrect encryption key for a connection.
This patch fixes the issue by always specifying to the LTK lookup
functions whether we're looking for a master or a slave key.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
All callers of hci_add_ltk pass a valid value to it. There are no places
where e.g. user space, the controller or the remote peer would be able
to cause invalid values to be passed. Therefore, just remove the
potentially confusing check from the beginning of the function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Instead of magic bitwise operations simply compare with the two possible
type values that we are interested in.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The code was previously iterating the wrong list (and what's worse
casting entries to a type which they were not) and also missing a proper
line terminator when printing each entry. The code now also prints the
LTK type in hex for easier comparison with the kernel-defined values.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Starting with the 4.1 Core Specification these flags are no longer used
and should always be cleared. From volume 3, part C, section 13.1.1:
"The 'Simultaneous LE and BR/EDR to Same Device Capable (Controller)'
and ‘Simultaneous LE and BR/EDR to Same Device Capable (Host)’ bits in
the Flags AD type shall be set to ‘0’."
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
So far we've only been requesting the LTK to be distributed to the
master (initiator) of pairing, which is usually enough since it's the
master that will establish future connections and initiate encryption.
However, in the case that both devices support switching to the opposing
role (which seems to be increasingly common) pairing will have to
performed again since the "new" master will not have all information.
As there is no real harm in it, this patch updates the code to always
try distributing the LTK also to the slave device, thereby enabling role
switches for future connections.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Vinicius Gomes <vcgomes@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch increments the management interface revision due to the
various fixes, improvements and other changes that have been made.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Now that ATT sockets have been converted to use the new L2CAP_CHAN_FIXED
type there is no need to have an extra check for chan->psm in the
l2cap_chan_close function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The l2cap_chan->psm value is always set to a valid value for a
connection oriented channel. The l2cap_chan->sport is used for tracking
local PSM allocations but will not always have a proper value, such as
with connected sockets derived from a listening socket. This patch fixes
the sock_getname callback to always use chan->psm when returning address
information.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When we're not connected the peer address information is undefined. This
patch fixes the remote address getting to return a proper error in case
the sate is anything else than BT_CONNECTED.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When we're not connected the peer address information is undefined. This
patch fixes the remote address getting to return a proper error in case
the state is anything else than BT_CONNECTED.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The sport variable is used to track the allocation of the local PSM
database to ensure no two sockets take the same local PSM. It is
acquired upon bind() but needs to be freed up if the socket ends up
becoming a client one. This patch adds the clearing of the value when
l2cap_chan_connect is called.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The L2CAP specification requires us to disconnect an L2CAP channel if
the remote side gives us credits beyond 65535. This patch makes sure we
disconnect the channel in such a situation.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The L2CAP specification requires us to disconnect a channel if the
remote device sends us data when it doesn't have any credits to do so.
This patch makes sure that we send the appropriate L2CAP Disconnect
request in this situation.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
There's a le_default_mps variable that can be modified through debugfs
but it was never actually used for determining our MPS value. This patch
fixes the MPS initialization to use the variable instead of a fixed
value.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Fixed channels have the same source and destination CID. Ensure that the
values get properly initialized when receiving incoming connections and
deriving values from the parent socket.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The BT_SECURITY option should also be allowed for fixed channels, so
punch the appropriate hole for it when checking for the channel type.
The main user of fixed CID user space sockets is right now ATT (which is
broken without this patch).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
ATT channels are not connection oriented so having them use
L2CAP_CHAN_CONN_ORIENTED is quite confusing. Instead, use the new
L2CAP_CHAN_FIXED type and ensure that the MTU and CID values get
properly set.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
There's no reason why A2MP should need or deserve its on channel type.
Instead we should be able to group all fixed CID users under a single
channel type and reuse as much code as possible for them. Where CID
specific exceptions are needed the chan-scid value can be used.
This patch renames the current A2MP channel type to a generic one and
thereby paves the way to allow converting ATT and SMP (and any future
fixed channel protocols) to use the new channel type.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The only user of l2cap_seq_list_remove() was l2cap_seq_list_pop() which
only removes the head, meaning only the "else if (seq_list->head ==
seq)" branch was ever being used. This patch moves the code from this
branch straight into l2cap_seq_list_pop() and removes the (now useless)
l2cap_seq_list_remove().
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch adds a queue for incoming L2CAP data that's received before
l2cap_connect_cfm is called and processes the data once
l2cap_connect_cfm is called. This way we ensure that we have e.g. all
remote features before processing L2CAP signaling data (which is very
important for making the correct security decisions).
The processing of the pending rx data needs to be done through
queue_work since unlike l2cap_recv_acldata, l2cap_connect_cfm is called
with the hci_dev lock held which could cause potential deadlocks.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch moves the l2cap_conn_add, is_valid_psm and l2cap_chan_connect
functions further down in l2cap_core.c. The patch doesn't contain
anything else except the relocation of these functions. By moving the
functions further down the patch enables a subsequent patch that adds a
pending RX queue to be implemented without a forward declaration of a
function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
For debugging purposes of Secure Connection Only support a simple
debugfs entry is used to indicate if this mode is active or not.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
With the introduction of security level 4, the RFCOMM sockets need to
be made aware of this new level. This change ensures that the pairing
requirements are set correctly for these connections.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
With the introduction of security level 4, the L2CAP sockets need to
be made aware of this new level. This change ensures that the pairing
requirements are set correctly for these connections.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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>
It is important to know if Secure Connections support has been enabled
for a given remote device. The information is provided in the remote
host features page. So track this information and provide a simple
helper function to extract the status.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The NOT_PAIRED status is only really suitable for operations where being
paired is a pre-requisite. Using it e.g. for the mgmt_pair_device
command seems unintuitive. In the case that either the local or the
remote user responds with a negative PIN Code response the "PIN or Key
Missing" HCI status will be generated. This patch changes the mapping of
this status from the NOT_PAIRED mgmt status to the more intuitive
AUTH_FAILED mgmt status.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Use ATTRIBUTE_GROUPS macro to reduce the number of lines of code.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The current management interface only allows to provide the remote
OOB input of P-192 data. This extends the command to also accept
P-256 data as well. To make this backwards compatible, the userspace
can decide to only provide P-192 data or the combined P-192 and P-256
data. It is also allowed to leave the P-192 data empty if userspace
only has the remote P-256 data.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Add function to allow adding P-192 and P-256 data to the internal
storage. This also fixes a few coding style issues from the previous
helper functions for the out-of-band credentials storage.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When Secure Connections has been enabled it is possible to provide P-192
and/or P-256 data during the pairing process. The internal out-of-band
credentials storage has been extended to also hold P-256 data.
Initially the P-256 data will be empty and with Secure Connections enabled
no P-256 data will be provided. This is according to the specification
since it might be possible that the remote side did not provide either
of the out-of-band credentials.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Bluetooth 4.1 specification with Secure Connections support has
just been released and controllers with this feature are still in
an early stage.
A handful of controllers have already support for it, but they do
not always identify this feature correctly. This debugfs entry
allows to tell the kernel that the controller can be treated as
it would fully support Secure Connections.
Using debugfs to force Secure Connections support of course does
not make this feature magically appear in all controllers. This
is a debug functionality for early adopters. Once the majority
of controllers matures this quirk will be removed.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
For Secure Connections support and the usage of out-of-band pairing,
it is needed to read the P-256 hash and randomizer or P-192 hash and
randomizer. This change will read P-192 data when Secure Connections
is disabled and P-192 and P-256 data when it is enabled.
The difference is between using HCI Read Local OOB Data and using the
new HCI Read Local OOB Extended Data command. The first one has been
introduced with Bluetooth 2.1 and returns only the P-192 data.
< HCI Command: Read Local OOB Data (0x03|0x0057) plen 0
> HCI Event: Command Complete (0x0e) plen 36
Read Local OOB Data (0x03|0x0057) ncmd 1
Status: Success (0x00)
Hash C from P-192: 975a59baa1c4eee391477cb410b23e6d
Randomizer R with P-192: 9ee63b7dec411d3b467c5ae446df7f7d
The second command has been introduced with Bluetooth 4.1 and will
return P-192 and P-256 data.
< HCI Command: Read Local OOB Extended Data (0x03|0x007d) plen 0
> HCI Event: Command Complete (0x0e) plen 68
Read Local OOB Extended Data (0x03|0x007d) ncmd 1
Status: Success (0x00)
Hash C from P-192: 6489731804b156fa6355efb8124a1389
Randomizer R with P-192: 4781d5352fb215b2958222b3937b6026
Hash C from P-256: 69ef8a928b9d07fc149e630e74ecb991
Randomizer R with P-256: 4781d5352fb215b2958222b3937b6026
The change for the management interface is transparent and no change
is required for existing userspace. The Secure Connections feature
needs to be manually enabled. When it is disabled, then userspace
only gets the P-192 returned and with Secure Connections enabled,
userspace gets P-192 and P-256 in an extended structure.
It is also acceptable to just ignore the P-256 data since it is not
required to support them. The pairing with out-of-band credentials
will still succeed. However then of course no Secure Connection will
b established.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The link keys that are loaded by userspace during controller setup
should be limited to actual valid and supported types. With the
support for Secure Connections, it is limited to types 0x00 - 0x08
at the moment. Reject any other link key types.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
If support for Secure Connection has been configured, then make sure
to send the appropiate HCI command to enable it when powering on the
controller.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The support for Secure Connections need to be explicitly enabled by
userspace. This is required since only userspace that can handle the
new link key types should enable support for Secure Connections.
This command handling is similar to how Secure Simple Pairing enabling
is done. It also tracks the case when Secure Connections support is
enabled via raw HCI commands. This makes sure that the host features
page is updated as well.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The MGMT_SETTING_SECURE_CONN setting is used to track the support and
status for Secure Connections from the management interface. For HCI
based tracking HCI_SC_ENABLED flag is used.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
With Secure Connections capable controllers, the authenticated payload
timeout can trigger. Enable the event so the controller informs the
host when this happens.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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>
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>
The check for HIGH security level dates back to pre-mgmt times when a
raw L2CAP socket with HIGH security level was used to trigger dedicated
bonding. For legacy pairing checking for the security level was the only
way to catch the need to authenticate in all scenarios. With mgmt
however, the pair_device command does not use HIGH security but MEDIUM
security. Therefore, the existing code would never trigger
authentication for a non-SSP connection without an MITM requirement
(e.g. if user space provided a NoInputNoOutput IO capability). In such a
scenario the mgmt_pair_device command would return success without
actually triggering any kind of pairing.
This patch updates the authentication requirement check to also consider
MEDIUM security level, and thereby ensures that mgmt_pair_device will
always trigger authentication.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit f38a5181d9 ("ceph: Convert to immutable biovecs") introduced
a NULL pointer dereference, which broke rbd in -rc1. Fix it.
Cc: Kent Overstreet <kmo@daterainc.com>
Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Handling redirect replies requires both map_sem and request_mutex.
Taking map_sem unconditionally near the top of handle_reply() avoids
possible race conditions that arise from releasing request_mutex to be
able to acquire map_sem in redirect reply case. (Lock ordering is:
map_sem, request_mutex, crush_mutex.)
Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
Factor out logic from ceph_osdc_start_request() into a new helper,
__ceph_osdc_start_request(). ceph_osdc_start_request() now amounts to
taking locks and calling __ceph_osdc_start_request().
Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
This capabilities weren't propagated to the radiotap header.
We don't set here the VHT_KNOWN / MCS_HAVE flag because not
all the low level drivers will know how to properly flag
the frames, hence the low level driver will be in charge
of setting IEEE80211_RADIOTAP_MCS_HAVE_FEC,
IEEE80211_RADIOTAP_MCS_HAVE_STBC and / or
IEEE80211_RADIOTAP_VHT_KNOWN_STBC according to its
capabilities.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ieee80211_rx_status.flags is full. Define a new vht_flag
variable to be able to set more VHT related flags and make
room in flags.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> [ath10k]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The purpose of this housekeeping is to make some room for
VHT flags. The radiotap vendor fields weren't in use.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In association request frames, there may be IEs passed from
userspace (such as interworking IEs) between HT and VHT, so
add code to insert those inbetween them.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In probe request frames, the VHT IEs should come before any
vendor IEs, but after interworking and similar, so add code
to order them correctly wrt. the IEs passed from userspace.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Update the operating mode field is needed when an association
request contains the operating mode notification element and
it's not just changed later on the fly.
Signed-off-by: Marek Kwaczynski <marek.kwaczynski@tieto.com>
[clarify commit log, comments & fix whitespace]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In case we will get regulatory request with rule
where max_bandwidth_khz is set to 0 handle this
case as a special one.
If max_bandwidth_khz == 0 we should calculate maximum
available bandwidth base on all frequency contiguous rules.
In case we need auto calculation we just have to set:
country PL: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20)
(5170 - 5250 @ AUTO), (N/A, 20)
(5250 - 5330 @ AUTO), (N/A, 20), DFS
(5490 - 5710 @ 80), (N/A, 27), DFS
This mean we will calculate maximum bw for rules where
AUTO (N/A) were set, 160MHz (5330 - 5170) in example above.
So we will get:
(5170 - 5250 @ 160), (N/A, 20)
(5250 - 5330 @ 160), (N/A, 20), DFS
In other case:
country FR: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20)
(5170 - 5250 @ AUTO), (N/A, 20)
(5250 - 5330 @ 80), (N/A, 20), DFS
(5490 - 5710 @ 80), (N/A, 27), DFS
We will get 80MHz (5250 - 5170):
(5170 - 5250 @ 80), (N/A, 20)
(5250 - 5330 @ 80), (N/A, 20), DFS
Base on this calculations we will set correct channel
bandwidth flags (eg. IEEE80211_CHAN_NO_80MHZ).
We don't need any changes in CRDA or internal regulatory.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
[extend nl80211 description a bit, fix typo]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
It was possible to break interface combinations in
the following way:
combo 1: iftype = AP, num_ifaces = 2, num_chans = 2,
combo 2: iftype = AP, num_ifaces = 1, num_chans = 1, radar = HT20
With the above interface combinations it was
possible to:
step 1. start AP on DFS channel by matching combo 2
step 2. start AP on non-DFS channel by matching combo 1
This was possible beacuse (step 2) did not consider
if other interfaces require radar detection.
The patch changes how cfg80211 tracks channels -
instead of channel itself now a complete chandef
is stored.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When receiving an IBSS_JOINED event select the BSS object
based on the {bssid, channel} couple rather than the bssid
only.
With the current approach if another cell having the same
BSSID (but using a different channel) exists then cfg80211
picks up the wrong BSS object.
The result is a mismatching channel configuration between
cfg80211 and the driver, that can lead to any sort of
problem.
The issue can be triggered by having an IBSS sitting on
given channel and then asking the driver to create a new
cell using the same BSSID but with a different frequency.
By passing the channel to cfg80211_get_bss() we can solve
this ambiguity and retrieve/create the correct BSS object.
All the users of cfg80211_ibss_joined() have been changed
accordingly.
Moreover WARN when cfg80211_ibss_joined() gets a NULL
channel as argument and remove a bogus call of the same
function in ath6kl (it does not make sense to call
cfg80211_ibss_joined() with a zero BSSID on ibss-leave).
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: Arend van Spriel <arend@broadcom.com>
Cc: Bing Zhao <bzhao@marvell.com>
Cc: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Cc: libertas-dev@lists.infradead.org
Acked-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
[minor code cleanup in ath6kl]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This patch moves the rfkill poll_work to the power efficient workqueue.
This work does not have to be bound to the CPU that scheduled it, hence
the selection of CPU that executes it would be left to the scheduler.
Net result is that CPU idle times would be extended, resulting in power
savings.
This behaviour is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com>
[zoran.markovic@linaro.org: Rebased to latest kernel, added commit message.
Fixed workqueue selection after suspend/resume cycle.]
Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For better use of CPU idle time, allow the scheduler to select the CPU
on which the timeout work of regulatory settings would be executed.
This extends CPU idle residency time and saves power.
This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com>
[zoran.markovic@linaro.org: Rebased to latest kernel. Added commit message.]
Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Action, disassoc and deauth frames are bufferable, and as such don't
have the PM bit in the frame control field reserved which means we
need to react to the bit when receiving in such a frame.
Fix this by introducing a new helper ieee80211_is_bufferable_mmpdu()
and using it for the RX path that currently ignores the PM bit in
any non-data frames for doze->wake transitions, but listens to it in
all frames for wake->doze transitions, both of which are wrong.
Also use the new helper in the TX path to clean up the code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Compiling with W=1 found a few variables that are set
but not used (-Wunused-but-set-variable), remove them.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add helper function that will return regdomain.
Follow the driver's regulatory domain, if present,
unless a country IE has been processed or a user
wants to help compliance further.
Signed-off-by: Janusz Dziedzic <janusz.dziedzi@tieto.com>
[remove useless reg variable]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Set preset_chandef in channel switch notification.
In other case we will have old preset_chandef.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Responding to probe requests for scanning clients will often create
excessive retries, as it happens quite often that the scanning client
already left the channel. Therefore do it like hostapd and send probe
responses for wildcard SSID only once by using the noack flag.
Signed-off-by: Simon Wunderlich <simon@open-mesh.com>
[fix typo & 'wildcard SSID' in commit log]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The scheduled scan matchsets were intended to be a list of filters,
with the found BSS having to pass at least one of them to be passed
to the host. When the RSSI attribute was added, however, this was
broken and currently wpa_supplicant adds that attribute in its own
matchset; however, it doesn't intend that to mean that anything
that passes the RSSI filter should be passed to the host, instead
it wants it to mean that everything needs to also have higher RSSI.
This is semantically problematic because we have a list of filters
like [ SSID1, SSID2, SSID3, RSSI ] with no real indication which
one should be OR'ed and which one AND'ed.
To fix this, move the RSSI filter attribute into each matchset. As
we need to stay backward compatible, treat a matchset with only the
RSSI attribute as a "default RSSI filter" for all other matchsets,
but only if there are other matchsets (an RSSI-only matchset by
itself is still desirable.)
To make driver implementation easier, keep a global min_rssi_thold
for the entire request as well. The only affected driver is ath6kl.
I found this when I looked into the code after Raja Mani submitted
a patch fixing the n_match_sets calculation to disregard the RSSI,
but that patch didn't address the semantic issue.
Reported-by: Raja Mani <rmani@qti.qualcomm.com>
Acked-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The ieee80211_vif_use_channel() function calls
ieee80211_vif_release_channel(), so there's no need to call it
explicitly in __ieee80211_sta_join_ibss().
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The patch adds a missing sdata lock and adds a few
lockdeps for easier maintenance.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
radar_required setting wasn't protected by
local->mtx in some places. This should prevent
from scanning/radar detection/roc colliding.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The sdata->vif.csa_active could be left set after,
e.g. channel context constraints check fail in STA
mode leaving the interface in a strange state for
a brief period of time until it is disconnected.
This was harmless but ugly.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If CSA for AP interface failed and the interface
was not stopped afterwards another CSA request
would leak sdata->u.ap.next_beacon.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of having
ieee80211_bss_info_change_notify() scattered all
over the place just call it once when finalizing
CSA.
As a side effect this patch adds missing error
checking for IBSS CSA beacon update.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
[fix err vs. changed variable usage in ieee80211_csa_finalize()]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are a few cases, e.g. suspend, where an AP interface is
stopped by the kernel rather than by userspace request, most
commonly when suspending. To let userspace know about this,
send the NL80211_CMD_STOP_AP command as an event every time
an AP interface is stopped. This also happens when userspace
did in fact request the AP stop, but that's not a problem.
For full-MAC drivers this may need to be extended to also
cover cases where the device stopped the AP operation for
some reason, this a bit more complicated because then all
cfg80211 state also needs to be reset; such API is not part
of this patch.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
A few places weren't checking that the frame passed to the
function actually has enough data even though the function
clearly documents it must have a payload byte. Make this
safer by changing the function to take an skb and checking
the length inside. The old version is preserved for now as
the rtl* drivers use it and don't have a correct skb.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If there's a policy, then nla_parse() return values must be
checked, otherwise the policy is useless and there's nothing
that ensures the attributes are actually what we expect them
to be.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ATM, {ADD,DEL}BA and BAR frames are sent on the AC matching the TID of
the BA parameters. In the discussion [1] about this patch, Johannes
recalled that it fixed some races with the DELBA and indeed this
behavior was introduced in [2].
While [2] is right for the BARs, the part queueing the {ADD,DEL}BAs on
their BA params TID AC violates the spec and is more a workaround for
some drivers. Helmut expressed some concerns wrt such drivers, in
particular DELBAs in rt2x00.
ATM, DELBAs are sent after a driver has called (hence "purposely")
ieee80211_start_tx_ba_cb_irqsafe and Johannes and Emmanuel gave some
details wrt intentions behind the split of the IEEE80211_AMPDU_TX_STOP_*
given to the driver ampdu_action supposed to call this function, which
could prove handy to people trying to do the right thing in faulty
drivers (if their fw/hw don't get in their way).
[1] http://mid.gmane.org/1390391564-18481-1-git-send-email-karl.beldan@gmail.com
[2] Commit: cf6bb79ad8 ("mac80211: Use appropriate TID for sending BAR, ADDBA and DELBA frames")
Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's not a single rate control algorithm actually in
a separate module where the module refcount would be
required. Similarly, there's no specific rate control
module.
Therefore, all the module handling code in rate control
is really just dead code, so remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The sample table is initialized only once at module start, so
is really __read_mostly. Additionally, the code to init it can
be marked __init since it will never be needed again, it is
likely automatically inlined into the __init function already
by the compiler, so this doesn't really make a difference.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The wiphy privid (to identify wiphys) and the cfg80211
ops should both be const, so change them to be.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Change the code to allow making all the rate control ops
const, nothing ever needs to change them. Also change all
drivers to make use of this and mark the ops const.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Restrict our published beamformee STS capability according
to the AP value.
Some AP show bad behaviour in interoperability testing
when our capabilities are better.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Initialize the buffer to all zeroes, otherwise the stack
data might be interpreted as the TID, which is likely to
fail completely.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In case the given ROC duration is 0, update it to a minimal value before
setting the ieee80211_roc_work parameters, so it also would be valid
for cases where scan is in progress or there are other ROCs queued.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since we copy the mesh_id_len into our own data structures,
use it consistently and don't sometimes use cfg80211's copy.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The mesh_id is an array so can't ever be NULL, it looks
like mesh_id_len check was intended instead. However,
since the previous patch, cfg80211 does the check, so
just remove it here.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Before allowing userspace to initiate a channel switch, check
that it's actually connected in some sense. Also use a more
appropriate error code for the not connected case.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The mesh precedence value in ieee80211_channel_switch
should be incremented or set to 1 only if this is the
initiator of mesh channel switch. For non-initiator,
the precedence value has updated using the Mesh
Channel Switch Parameters element. Fix this.
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fix the following issues in reg_process_hint():
1. Add verification that wiphy is valid before processing
NL80211_REGDOMAIN_SET_BY_COUNTRY_IE.
2. Free the request in case of invalid initiator.
3. Remove WARN_ON check on reg_request->alpha2 as it is not a
pointer.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When IEEE80211_HW_SIGNAL_UNSPEC is set, mac80211 will perform a
division by max_signal in ieee80211_bss_info_update. If max_signal
is not properly set by the driver (for example it is zero) this
leads to a divide error and crash.
Thanks to Larry Finger, who pointed me to this.
This patch adds in ieee80211_register_hw one more check to detect
this condition and eventually returns -EINVAL, as already done for
other checks already performed there.
Signed-off-by: andrea merello <andrea.merello@gmail.com>
[move to an already existing SIGNAL_UNSPEC check]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Commit 7ec7c4a9a6 ("mac80211: port CCMP to cryptoapi's CCM driver")
resulted in the 'encrypted' param of ccmp_special_blocks() to be no
longer used so it can be dropped from the prototype.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Allow to force SGI, LGI.
Mainly for test purpose.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Addition of the frequency hints showed up couple of places in cfg80211
where pointers could be marked const and a shared function could be used
to fetch a valid channel.
Signed-off-by: Jouni Malinen <j@w1.fi>
[fix mwifiex]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
