- 03 Feb, 2015 1 commit
-
-
Mika Westerberg authored
This is yet another Broadcom bluetooth chip with ACPI ID BCM2E40. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 29 Jan, 2015 1 commit
-
-
Johannes Berg authored
Such a feature doesn't exist and isn't really needed since you probably won't have enough interfaces to make it worthwhile, so just remove that from the documentation. Reported-by: booto [on IRC] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 28 Jan, 2015 1 commit
-
-
Sharon Dvir authored
'make pdfdocs' failed for 80211.tmpl and reported errors of the form: 'document type does not allow element "refentry" here' Fix this by moving </section> tags to a location that makes sense, this fixes the errors and the pdf looks OK in relevant areas. Signed-off-by: Sharon Dvir <sharon.dvir1@mail.huji.ac.il> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 27 Jan, 2015 8 commits
-
-
Jouni Malinen authored
This allows mac80211 to configure BIP-GMAC-128 and BIP-GMAC-256 to the driver and also use software-implementation within mac80211 when the driver does not support this with hardware accelaration. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Jouni Malinen authored
This allows mac80211 to configure BIP-CMAC-256 to the driver and also use software-implementation within mac80211 when the driver does not support this with hardware accelaration. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Jouni Malinen authored
This allows mac80211 to configure CCMP-256 to the driver and also use software-implementation within mac80211 when the driver does not support this with hardware accelaration. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> [squash ccmp256 -> mic_len argument change] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Jouni Malinen authored
This allows mac80211 to configure GCMP and GCMP-256 to the driver and also use software-implementation within mac80211 when the driver does not support this with hardware accelaration. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> [remove a spurious newline] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Jouni Malinen authored
This makes cfg80211 aware of the GCMP, GCMP-256, CCMP-256, BIP-GMAC-128, BIP-GMAC-256, and BIP-CMAC-256 cipher suites. These new cipher suites were defined in IEEE Std 802.11ac-2013. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Jouni Malinen authored
This cipher can be used only as a group management frame cipher and as such, there is no point in validating that it is not used with non-zero key-index. Instead, verify that it is not used as a pairwise cipher regardless of the key index. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> [change code to use switch statement which is easier to extend] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The ath10k driver only supports HW crypto (except for management frames or so - CMAC needs to be done in software). Make it use the new IEEE80211_HW_SW_CRYPTO_CONTROL flag to ensure mac80211 doesn't erroneously attempt to use software crypto. Taking through my tree after Kalle's ACK to avoid breaking the ath10k driver with the next crypto patches. Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Luciano Coelho authored
If suspend starts while ieee80211_scan_completed() is running, between the point where SCAN_COMPLETED is set and the work is queued, ieee80211_scan_cancel() will not catch the work and we may finish suspending before the work is actually executed, leaving the scan running while suspended. To fix this race, queue the scan work during resume if the SCAN_COMPLETED flag is set and flush it immediately. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 23 Jan, 2015 12 commits
-
-
Johannes Berg authored
For drivers without beacon filtering, support beacon statistics entirely, i.e. report the number of beacons and average signal. For drivers with beacon filtering, give them the number of beacons received by mac80211 -- in case the device reports only the number of filtered beacons then driver doesn't have to count all beacons again as mac80211 already does. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
In the case of non-QoS association, the counter was actually wrong. The right index isn't security_idx but seqno_idx, as security_idx will be 0 for data frames, while 16 is needed. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
These conditions are rather difficult to follow, for example because "!sta" only exists to not crash in the case that we don't have a station pointer (WLAN_TDLS_SETUP_REQUEST) in which the additional condition (peer supports HT) doesn't actually matter anyway. Cleaning this up only duplicates two lines of code but makes the rest far easier to read, so do that. As a side effect, smatch stops complaining about the lack of a sta pointer test after the !sta (since the !sta goes away) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
There's no need to use another local 'sta' variable as the original (outer scope) one isn't needed any more and has become invalid anyway when exiting the RCU read section. Remove the inner scope one and along with it the useless NULL initialization. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
smatch warns that we once checked request->ssids in two functions and then unconditionally used it later again. This is actually fine, because the code has a relationship between attrs[NL80211_ATTR_SCAN_SSIDS], n_ssids and request->ssids, but smatch isn't smart enough to realize that. Suppress the warnings by always checking just n_ssids - that way smatch won't know that request->ssids could be NULL, and since it is only NULL when n_ssids is 0 we still check everything correctly. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Bob Copeland authored
This reverts commit 2ae70efc. The new peer events that are generated by the change are causing problems with wpa_supplicant in userspace: wpa_s tries to restart SAE authentication with the peer when receiving the event, even though authentication may be in progress already, and it gets very confused. Revert back to the original operating mode, which is to only get events when there is no corresponding station entry. Cc: Nishikawa, Kenzoh <Kenzoh.Nishikawa@jp.sony.com> Cc: Masashi Honma <masashi.honma@gmail.com> Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Luciano Coelho authored
It is possible that a deferred scan is queued after the queues are flushed in __ieee80211_suspend(). The deferred scan work may be scheduled by ROC or ieee80211_stop_poll(). To make sure don't start a new scan while suspending, check whether we're quiescing or suspended and complete the scan immediately if that's the case. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
When we go to suspend, there is complex set of states that avoids races. The quiescing variable is set whlie __ieee80211_suspend is running. Then suspended is set. The code makes sure there is no window without any of these flags. The problem is that workers can still be enqueued while we are quiescing. This leads to situations where the driver is already suspending and other flows like disassociation are handled by a worker. To fix this, we need to check quiescing and suspended flags in the worker itself and not only before enqueueing it. I also add here extensive documentation to ease the understanding of these complex issues. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
When mac80211 disconnects, it drops all the packets on the queues. This happens after the net stack has been notified that we have no link anymore (netif_carrier_off). netif_carrier_off ensures that no new packets are sent to xmit() callback, but we might have older packets in the middle of the Tx path. These packets will land in the driver's queues after the latter have been flushed. Synchronize_net() between netif_carrier_off and drv_flush() will fix this. Note that we can't call synchronize_net inside ieee80211_flush_queues since there are flows that call ieee80211_flush_queues and don't need synchronize_net() which is an expensive operation. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> [reword comment to be more accurate] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Luciano Coelho authored
The userspace may want to delay the the first scheduled scan or net-detect cycle. Add an optional attribute to the scheduled scan configuration to pass the delay to be (optionally) used by the driver. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> [add the attribute to the policy to validate it] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Lorenzo Bianconi authored
Control per packet Transmit Power Control (TPC) in lower drivers according to TX power settings configured by the user. In particular TPC is enabled if value passed in enum nl80211_tx_power_setting is NL80211_TX_POWER_LIMITED (allow using less than specified from userspace), whereas TPC is disabled if nl80211_tx_power_setting is set to NL80211_TX_POWER_FIXED (use value configured from userspace) Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Vadim Kochan authored
Added new NL80211_ATTR_NETNS_FD which allows to set namespace via nl80211 by fd. Signed-off-by: Vadim Kochan <vadim4j@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 22 Jan, 2015 1 commit
-
-
Johannes Berg authored
Some drivers unfortunately cannot support software crypto, but mac80211 currently assumes that they do. This has the issue that if the hardware enabling fails for some reason, the software fallback is used, which won't work. This clearly isn't desirable, the error should be reported and the key setting refused. Support this in mac80211 by allowing drivers to set a new HW flag IEEE80211_HW_SW_CRYPTO_CONTROL, in which case mac80211 will only allow software fallback if the set_key() method returns 1. The driver will also need to advertise supported cipher suites so that mac80211 doesn't advertise any (future) software ciphers that the driver can't actually do. While at it, to make it easier to support this, refactor the ieee80211_init_cipher_suites() code. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 21 Jan, 2015 1 commit
-
-
Johannes Berg authored
Station info state is started in allocation, so should be destroyed on free (it's just a timer); rate control must be freed if anything afterwards fails to initialize. LED exit should be later, no need for locking there, but it needs to be done also when rate init failed. Also clean up the code by moving a label so the locking doesn't have to be done separately. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 19 Jan, 2015 2 commits
-
-
Emmanuel Grumbach authored
While suspending, we destroy the authentication / association that might be taking place. While doing so, we forgot to delete the timer which can be firing after local->suspended is already set, producing the warning below. Fix that by deleting the timer. [66722.825487] WARNING: CPU: 2 PID: 5612 at net/mac80211/util.c:755 ieee80211_can_queue_work.isra.18+0x32/0x40 [mac80211]() [66722.825487] queueing ieee80211 work while going to suspend [66722.825529] CPU: 2 PID: 5612 Comm: kworker/u16:69 Tainted: G W O 3.16.1+ #24 [66722.825537] Workqueue: events_unbound async_run_entry_fn [66722.825545] Call Trace: [66722.825552] <IRQ> [<ffffffff817edbb2>] dump_stack+0x4d/0x66 [66722.825556] [<ffffffff81075cad>] warn_slowpath_common+0x7d/0xa0 [66722.825572] [<ffffffffa06b5b90>] ? ieee80211_sta_bcn_mon_timer+0x50/0x50 [mac80211] [66722.825573] [<ffffffff81075d1c>] warn_slowpath_fmt+0x4c/0x50 [66722.825586] [<ffffffffa06977a2>] ieee80211_can_queue_work.isra.18+0x32/0x40 [mac80211] [66722.825598] [<ffffffffa06977d5>] ieee80211_queue_work+0x25/0x50 [mac80211] [66722.825611] [<ffffffffa06b5bac>] ieee80211_sta_timer+0x1c/0x20 [mac80211] [66722.825614] [<ffffffff8108655a>] call_timer_fn+0x8a/0x300 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This reverts commit ba1debdf. Oliver reported that it breaks network-manager, for some reason with this patch NM decides that the device isn't wireless but "generic" (ethernet), sees no carrier (as expected with wifi) and fails to do anything else with it. Revert this to unbreak userspace. Reported-by: Oliver Hartkopp <socketcan@hartkopp.net> Tested-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 16 Jan, 2015 2 commits
-
-
Johannes Berg authored
The return value from nl80211_send_station() is the length of the skb, or a negative error, so abort sending the message only when the return value was negative. This fixes the ibss_rsn wpa_supplicant test case. Reported-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 15 Jan, 2015 3 commits
-
-
Johannes Berg authored
For some reason, we made the bandwidth separate flags, which is rather confusing - a single rate cannot have different bandwidths at the same time. Change this to no longer be flags but use a separate field for the bandwidth ('bw') instead. While at it, add support for 5 and 10 MHz rates - these are reported as regular legacy rates with their real bitrate, but tagged as 5/10 now to make it easier to distinguish them. In the nl80211 API, the flags are preserved, but the code now can also clearly only set a single one of the flags. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
These rates are treated the same as 160 MHz in the spec, so it makes no sense to distinguish them. As no driver uses them yet, this is also not a problem, just remove them. In the userspace API the field remains reserved to preserve API and ABI. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
These rates are treated the same as 160 MHz in the spec, so it makes no sense to distinguish them. As no driver uses them yet, this is also not a problem, just remove them. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 14 Jan, 2015 8 commits
-
-
Johannes Berg authored
I removed the enum earlier, but forgot to remove it from the documentation - do that now. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Luciano Coelho authored
Send the netdetect configuration information in the response to NL8021_CMD_GET_WOWLAN commands. This includes the scan interval, SSIDs to match and frequencies to scan. Additionally, add the NL80211_WOWLAN_TRIG_NET_DETECT with NL80211_ATTR_WOWLAN_TRIGGERS_SUPPORTED. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Arik Nemtsov authored
When a system contains only self-managed regulatory devices all hints from the regulatory core are ignored. Stop hint processing early in this case. These systems usually don't have CRDA deployed, which results in endless (irrelevent) logs of the form: cfg80211: Calling CRDA to update world regulatory domain Make sure there's at least one self-managed device before discarding a hint, in order to prevent initial hints from disappearing on CRDA managed systems. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Arik Nemtsov authored
A self-managed device will sometimes need to set its regdomain synchronously. Notably it should be set before usermode has a chance to query it. Expose a new API to accomplish this which requires the RTNL. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Eliad Peller authored
Radar detection can last indefinite time. There is no point in deferring a scan request in this case - simply return -EBUSY. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Eliad Peller authored
ctx->conf.radar_enabled should reflect whether radar detection is enabled for the channel context. When calculating it, make it consider only the vifs that have this context assigned (instead of all the vifs). Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Eliad Peller authored
local->radar_detect_enabled should tell whether radar_detect is enabled on any interface belonging to local. However, it's not getting updated correctly in many cases (actually, when testing with hwsim it's never been set, even when the dfs master is beaconing). Instead of handling all the corner cases (e.g. channel switch), simply check whether radar detection is enabled only when needed, instead of caching the result. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Arik Nemtsov authored
The function adding the supported channels IE during a TDLS connection had several issues: 1. If the entire subband is usable, the function exitted the loop without adding it 2. The function only checked chandef_usable, ignoring flags like RADAR which would prevent TDLS off-channel communcation. 3. HT20 was explicitly required in the chandef, while not a requirement for TDLS off-channel. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-