This commit implements the TX side of NL80211_CMD_CONTROL_PORT_FRAME.
Userspace provides the raw EAPoL frame using NL80211_ATTR_FRAME.
Userspace should also provide the destination address and the protocol
type to use when sending the frame. This is used to implement TX of
Pre-authentication frames. If CONTROL_PORT_ETHERTYPE_NO_ENCRYPT is
specified, then the driver will be asked not to encrypt the outgoing
frame.
A new EXT_FEATURE flag is introduced so that nl80211 code can check
whether a given wiphy has capability to pass EAPoL frames over nl80211.
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This commit also adds cfg80211_rx_control_port function. This is used
to generate a CMD_CONTROL_PORT_FRAME event out to userspace. The
conn_owner_nlportid is used as the unicast destination. This means that
userspace must specify NL80211_ATTR_SOCKET_OWNER flag if control port
over nl80211 routing is requested in NL80211_CMD_CONNECT,
NL80211_CMD_ASSOCIATE, NL80211_CMD_START_AP or IBSS/mesh join.
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
[johannes: fix return value of cfg80211_rx_control_port()]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We already have 'ifmgd' here, and it's already assigned
to the same value, so remove the duplicate.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In the current implementation, mac80211 advertises the support of
AP_VLANs based on the driver's support for AP mode; it also
blocks encrypted AP_VLAN operation on devices advertising
SW_CRYPTO_CONTROL.
The implementation seems weird in it's current form and could be
often confusing, this is because there can be drivers advertising
both SW_CRYPTO_CONTROL and AP mode support (ex: ath10k) in which case
AP_VLAN will still be supported but only in open BSS and not in
secured BSS.
When SW_CRYPTO_CONTROL is enabled, it makes more sense if the decision
to support AP_VLANs is left to the driver. Mac80211 can then allow
AP_VLAN operations depending on the driver support.
Signed-off-by: Manikanta Pubbisetty <mpubbise@codeaurora.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In general regulatory self managed devices maintain their own
regulatory profiles thus it doesn't have to query the regulatory database
on country change.
ETSI has recently introduced a new channel access mechanism for 5GHz
that all wlan devices need to comply with.
These values are stored in the regulatory database.
There are self managed devices which can't maintain these
values on their own. Add API to allow self managed regulatory devices
to query the regulatory database for high band wmm rule.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
[johannes: fix documentation]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ETSI has recently added new requirements that restrict the WMM
parameter values for 5GHz frequencies. We need to take care of the
following scenarios in order to comply with these new requirements:
1. When using mac80211 default values;
2. When the userspace tries to configure its own values;
3. When associating to an AP which advertises WWM IE.
When associating to an AP, the client uses the values in the
advertised WMM IE. But the AP may not comply with the new ETSI
requirements, so the client needs to check the current regulatory
rules and use those limits accordingly.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The whole code is set up to allow RCU reads of this data, but
then uses rtnl_dereference() which requires the RTNL. Convert
it to rcu_dereference_rtnl() which makes it require only RCU
or the RTNL, to allow RCU-protected reading of the data.
Reviewed-by: Coelho, Luciano <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ETSI EN 301 893 v2.1.1 (2017-05) standard defines a new channel access
mechanism that all devices (WLAN and LAA) need to comply with.
The regulatory database can now be loaded into the kernel and also
has the option to load optional data.
In order to be able to comply with ETSI standard, we add wmm_rule into
regulatory rule and add the option to read its value from the regulatory
database.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
[johannes: fix memory leak in error path]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Remove the static array and use the generic routine to set the
Ethernet broadcast address.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Currently vdev stats displayed in fw_stats are applicable
only for TLV based firmware and fix it for 10.4 firmware
as of now. The vdev stats in 10.4 firmware is split into two
parts (vdev_stats, vdev_stats_extended). The actual stats
are captured only in extended vdev stats. In order to enable
vdev stats, appropriate feature bit will be set on extended
resource config. As FTM related counters are available only on
newer 10.4 based firmware, these counters will be displayed
only on valid data.
Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The commit "cfg80211: make RATE_INFO_BW_20 the default" changed
the index of RATE_INFO_BW_20, but the updates to ath10k missed
the special bandwidth calculation case in
ath10k_update_per_peer_tx_stats().
This will fix below warning,
WARNING: CPU: 0 PID: 609 at net/wireless/util.c:1254
cfg80211_calculate_bitrate+0x174/0x220
invalid rate bw=1, mcs=9, nss=2
(unwind_backtrace) from
(cfg80211_calculate_bitrate+0x174/0x220)
(cfg80211_calculate_bitrate) from
(nl80211_put_sta_rate+0x44/0x1dc)from
(nl80211_put_sta_rate) from
(nl80211_send_station+0x388/0xaf0)
(nl80211_get_station+0xa8/0xec)
[ end trace da8257d6a850e91a ]
Fixes: 842be75c77 ("cfg80211: make RATE_INFO_BW_20 the default")
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This patch fixes regression caused by 0c317a02ca
("cfg80211: support virtual interfaces with different beacon intervals"),
with this change cfg80211 expects the driver to advertize
'beacon_int_min_gcd' to support different beacon intervals in multivap
scenario. This support is added for, QCA988X/QCA99X0/QCA9984/QCA4019.
Verifed AP + mesh bring up on QCA9984 with beacon interval 100msec and
1000msec respectively.
Frimware: firmware-5.bin_10.4-3.5.3-00053
Fixes: 0c317a02ca ("cfg80211: support virtual interfaces with different beacon intervals")
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
For WPA encryption, QCA6174 firmware(version: WLAN.RM.4.4) will unblock
data when M4 was sent successfully. For other encryption which didn't need
4-way handshake firmware will unblock the data when peer authorized. Since
TDLS is 3-way handshake host need send authorize cmd to firmware to unblock
data.
Signed-off-by: Yingying Tang <yintang@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
TDLS peer do not need WEP key. Setting WEP key will lead
to TDLS setup failure. Add fix to avoid setting WEP key
for TDLS peer.
Signed-off-by: Yingying Tang <yintang@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Enable TDLS peer inactivity detetion feature.
QCA6174 firmware(version: WLAN.RM.4.4) support TDLS link inactivity detecting.
Set related parameters in TDLS WMI command to enable this feature.
Signed-off-by: Yingying Tang <yintang@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Enable TDLS peer buffer STA feature.
QCA6174 firmware(version: WLAN.RM.4.4) support TDLS peer buffer STA,
it reports this capability through wmi service map in wmi service ready
event. Set related parameter in TDLS WMI command to enable this feature.
Signed-off-by: Yingying Tang <yintang@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
In case wcn36xx_smd_rsp_process() is called more than once before
hal_ind_work was dispatched, the messages will end up in hal_ind_queue,
but wcn36xx_ind_smd_work() will only look at the first message in that
list.
Fix this by dequeing the messages from the list in a loop, and only stop
when it's empty.
This issue was found during a review of the driver. In my tests, that
race never actually occured.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
wcn36xx_start_tx function retrieves the buffer descriptor from the
channel control queue to start filling tx buffer information. However,
nothing prevents this same buffer to be concurrently accessed in a
concurent tx call, leading to potential buffer coruption and firmware
crash (observed during iperf test). The channel control queue should
only be accessed and updated with the channel lock.
Fix this issue by using a local buffer descriptor which will be copied
in the thread-safe wcn36xx_dxe_tx_frame.
Note that buffer descriptor size is few bytes so the introduced copy
overhead is insignificant. Moreover, this allows to keep the locked
section minimal.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Ramon Fried <rfried@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
It appears that the WCN36xx firmware doesn't actually respond to
probe requests. Until it's resolved, switch the probe response
responsibility to the 802.11 layer to allow creation of
hidden SSID AP's.
Signed-off-by: Ramon Fried <rfried@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
QCA9984/QCA99X0/QCA4019 chipsets have 8 memory regions, dump all of them to the
firmware coredump file. Some of the regions need to be read using ioread() so
add new region types for them.
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
[kvalo: refactoring etc]
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
As QCA9984 needs two region types refactor the code to make it easier add the
new types. No functional changes.
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
FW has Smart Logging feature enabled by default for detecting failures
and processing FATAL_CONDITION_EVENTID (36925 - 0x903D) back to host.
Since ath10k doesn't implement the Smart Logging and FATAL CONDITION
EVENT processing yet, suppressing the unknown event ID warning by moving
this under ATH10K_DBG_WMI.
Simulated the same issue by having associated STA powered off when
ping flood was running from AP backbone. This triggerd STA KICKOUT
in AP followed by FATAL CONDITION event 36925.
Issue was reproduced and verified in below DUT
------------------------------------------------
AP mode of OpenWRT QCA9984 running 6.0.8 with FW ver 10.4-3.5.3-00053
Signed-off-by: Sathishkumar Muruganandam <murugana@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Firmware WLAN.TF.2.1-00014-QCARMSWP-1 now supports reading the board ID
information and also required 9 IRAM bank, which older ath10k version
don't have the support will fail to be enabled, so in order to maintain
the backward compatibility, we need to update the FW API to 6.
Signed-off-by: Ryan Hsu <ryanhsu@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The firmware of QCA6174/QCA9377 already support the feature, just enable
it to be able to handle the get_temperature command and process the event.
You can read the temperature by using the hwmon interface,
cat /sys/class/ieee80211/phy*/device/hwmon/hwmon2/temp1_input
Verified with the following hardware and software combination,
QCA6174, only firmware-4.bin doesn't support this, otherwise all support.
QCA9377, all the firmwares upstreamed support this command
Signed-off-by: Ryan Hsu <ryanhsu@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
some userspace programs (e.g. hostapd) need to set the regulatory domain
before selecting the operating channel. Synchronize DFS detector regardless of
the value of ah->curchan, to avoid situations where wireless scan can't be done
on some 5GHz sub-bands, because dfs_region is constantly UNSET.
Acked-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Timothy Redaelli <tredaelli@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
[johannes: fix race with wdev lock/unlock by just acquiring once]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
[johannes: fix race with wdev lock/unlock by just acquiring once]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Fix a UBSAN warning;
* Improvement in the net-stack/driver log syncing
* An RCU lock fix in the new rate-scaling code;
* Support for new PCI IDs for the 9000 family;
* Support for a new API version;
* Initial work for supporting the new ETSI rules;
* Support for advanced dwell in scanning;
* Support for OCE in scanning;
* Some debugging improvements;
* Other small improvements and cleanups here and there.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEF3LNfgb2BPWm68smoUecoho8xfoFAlq7844ACgkQoUecoho8
xfrA4w/+Id8GUA7RpsH3rkdWYJbru9j4XzANGVgDqo1G52nuczAjWuT5Apdtb9Dc
ULwYpo8O9H4xLc3plF7RQ/NuqH5gLB+XpKFUbo6pN6tKOYXo6lyvAVjE9N6fhaxT
pbd2ZFyC7M6NAhyPIAC5n0MiLBQw57Y0Qiou/woowF/GGttP++XFLsCjU8h4bKui
NTenIfs8ht0t0KFw56JEiyMeUS8HcLa6fcnkTFkIZbyho5MlMJP8Yxnc0E7mwwOf
BWpwlRBCSJUghzW3MiWeSkU1+23IPbFFRdSRY3Suk0u1lFfWuIAKM0iqpg/BKeU9
EVrvFLQ+P8KjnfDV9zxTFL24oxw1YJ/Myss5nIAOFzKopco7FNdGbkW7HD2XVwVz
vjs5j57496lkC/Cb55zXbNLjrp1gL+16RlOcpKNmcS5khmv0NrKBj5RRkZQ8XOXD
TWBOcev89R58E6XnUijiEN96zZ7Ufdb56m3Xm/uvses/aoNFK5+QspMdPTeuI+VA
Pw+APOiTSWHW29Ndn93MNLlJoo02v/o/qWbPUkTN9iASyHowYuKqiC18o3vx8I/6
DFh86k1wNchgxlo8MbHrM2ginr/+LtQke+FsjczCRIRUH8ySFHthZtItr2Bl/kky
JQwC/R7AQT8iZWphA8aEQnXOaOuxwMve0QpKxHwAI4FUFHReUU0=
=8m6c
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-next-for-kalle-2018-03-28' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
iwlwifi patches for 4.14
* Fix a UBSAN warning;
* Improvement in the net-stack/driver log syncing
* An RCU lock fix in the new rate-scaling code;
* Support for new PCI IDs for the 9000 family;
* Support for a new API version;
* Initial work for supporting the new ETSI rules;
* Support for advanced dwell in scanning;
* Support for OCE in scanning;
* Some debugging improvements;
* Other small improvements and cleanups here and there.
Currently autodisconnect_wk assumes that only interface types of
P2P_CLIENT and STATION use conn_owner_nlportid. Change this so all
interface types are supported.
Signed-off-by: Denis Kenzior <denkenz@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently channel switch/start_ap to DFS channel cannot be done to
non-CAC-cleared channel even if DFS offload if enabled.
Make non-cleared DFS channels available if DFS offload is enabled.
CAC will be started by HW after channel change, start_ap call, etc.
Signed-off-by: Dmitry Lebed <dlebed@quantenna.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Exclude CAC_STARTED event from !wdev->cac_started check,
since cac_started will be set later in the same function.
Signed-off-by: Dmitry Lebed <dlebed@quantenna.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bandwidth change value reported via nl80211 contains mac80211
specific enum value(ieee80211_sta_rx_bw) and which is not
understand by userspace application. Map the mac80211 specific
value to nl80211_chan_width enum value to avoid using wrong value
in the userspace application. And used station's ht/vht capability
to map IEEE80211_STA_RX_BW_20 and IEEE80211_STA_RX_BW_160 with
proper nl80211 value.
Signed-off-by: Tamizh chelvam <tamizhr@codeaurora.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
SMPS_MODE change value notified via nl80211 contains mac80211
specific value(ieee80211_smps_mode) and user space application
will not know those values. This patch add support to map
the mac80211 enum value to nl80211_smps_mode which will be
understood by the userspace application.
Signed-off-by: Tamizh chelvam <tamizhr@codeaurora.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently bw and smps_mode are u8 type value in sta_opmode_info
structure. This values filled in mac80211 from ieee80211_sta_rx_bandwidth
and ieee80211_smps_mode. These enum values are specific to mac80211 and
userspace/cfg80211 doesn't know about that. This will lead to incorrect
result/assumption by the user space application.
Change bw and smps_mode parameters to their respective enums in nl80211.
Signed-off-by: Tamizh chelvam <tamizhr@codeaurora.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We can set triggers that cause a debug data collection when something
of interest happens (e.g. when too many probes are lost conscutively).
Normally, this triggers don't cause the FW to be restarted, but in
some cases that may be desired, so we recover from the problem. To
support this, add a flag that indicates that the FW should be
restarted when the trigger fires.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Currently we have a boolean variable for each cause.
This costs space, and requires to check each separately
when determining low latency.
Since we have another cause incoming, convert it to an enum.
While at it, move the retrieval of the prev value and the
assignment of the new value to be inside iwl_mvm_update_low_latency
and save the need for each caller to do it separately.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Some geographic profiles require specific handling. For example ETSI
profile requires special channel access handling. Add geographic
profile information to MCC_UPDATE response to allow it.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
A lot of new PCI IDs were added for the 9000 series. Add them to the
list of supported PCI IDs.
Cc: stable@vger.kernel.org # 4.13+
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Remove fragmented_dwell_time and add num_of_fragments to support
the new API version.
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The FW does not allocate quota air time for the binding of a station
MAC before iwlmvm indicates that it is associated. Currently iwlmvm
indicates that the MAC is associated only after hearing a beacon from
the AP. In case a deauthentication frame is sent before the MAC is
associated, the frame might not be sent as the corresponding binding
is not scheduled.
To handle such cases, set IEEE80211_HW_DEAUTH_NEED_MGD_TX_PREP in the
HW flags, requesting mac80211 to call the mgd_prepare_tx() callback
before transmitting a deauthentication frame if associated but no
beacon was heard from the AP.
In addition, do not warn in iwl_mvm_mac_mgd_prepare_tx() when already
associated as now the callback can be called also when associated.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Add support for Optimized Connectivity Experience (OCE). Get
capabilities from the fw, expose them with nl80211, and enable them in
UMAC scan if the relevant nl80211 flags are set by the userspace.
Signed-off-by: Roee Zamir <roee.zamir@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Update the scan command API with support for adaptive dwell. Adaptive
dwell is a type of scan that dynamically changes the time it remains
on each channel listening for beacons or probe responses.
Signed-off-by: Roee Zamir <roee.zamir@intel.com>
Signed-off-by: Beni Lev <beni.lev@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Sometimes iwl_mvm_disable_txq() may be called with mac80211_queue ==
IEEE80211_INVAL_HW_QUEUE, and this would cause us to use BIT(0xFF)
which is way too large for the u16 we used to store it in
hw_queue_to_mac820211. If this happens the following UBSAN warning
will be generated:
[ 167.185167] UBSAN: Undefined behaviour in drivers/net/wireless/intel/iwlwifi/mvm/utils.c:838:5
[ 167.185171] shift exponent 255 is too large for 64-bit type 'long unsigned int'
Fix that by checking that it is not IEEE80211_INVAL_HW_QUEUE and,
while at it, add a warning if the queue number is larger than
IEEE80211_MAX_QUEUES.
Fixes: 34e10860ae ("iwlwifi: mvm: remove references to queue_info in new TX path")
Reported-by: Paul Menzel <pmenzel+linux-wireless@molgen.mpg.de>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Denis Kenzior
Johannes Berg
Manikanta Pubbisetty
Haim Dreyfuss
Joe Perches
Rajkumar Manoharan
Christian Lamparter
Anilkumar Kolli
Yingying Tang
Daniel Mack
Loic Poulain
Ramon Fried
Kalle Valo
Sathishkumar Muruganandam
Ryan Hsu
Karthikeyan Periyasamy
Timothy Redaelli
Dmitry Lebed
tamizhr@codeaurora.org
Shahar S Matityahu
Sara Sharon
Emmanuel Grumbach
Luca Coelho
Ayala Beker
Ilan Peer
Zamir, Roee