- 28 2月, 2014 1 次提交
-
-
由 Johannes Berg 提交于
When a VHT network uses 20 or 40 MHz as per the HT operation information, the channel center frequency segment 0 field in the VHT operation information is reserved, so ignore it. This fixes association with such networks when the AP puts 0 into the field, previously we'd disconnect due to an invalid channel with the message wlan0: AP VHT information is invalid, disable VHT Cc: stable@vger.kernel.org Fixes: f2d9d270 ("mac80211: support VHT association") Reported-by: NTim Nelson <tim.l.nelson@gmail.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 24 2月, 2014 1 次提交
-
-
由 Johannes Berg 提交于
The MLME code in mac80211 must track whether or not the AP changed bandwidth, but if there's no change while tracking it shouldn't do anything, otherwise regulatory updates can make it impossible to connect to certain APs if the regulatory database doesn't match the information from the AP. See the precise scenario described in the code. This still leaves some possible problems with CSA or if the AP actually changed bandwidth, but those cases are less common and won't completely prevent using it. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=70881 Cc: stable@vger.kernel.org Reported-and-tested-by: NNate Carlson <kernel@natecarlson.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 11 2月, 2014 1 次提交
-
-
由 Eytan Lifshitz 提交于
In case ieee80211_prep_connection() fails to dereference sdata->vif.chanctx_conf, the function returns and doesn't free new_sta. fixed. Signed-off-by: NEytan Lifshitz <eytan.lifshitz@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 19 12月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
The scan code creates an iflist_mtx -> mtx locking dependency, and a few other places, notably radar detection, were creating the opposite dependency, causing lockdep to complain. As scan and radar detection are mutually exclusive, the deadlock can't really happen in practice, but it's still bad form. A similar issue exists in the monitor mode code, but this is only used by channel-context drivers right now and those have to have hardware scan, so that also can't happen. Still, fix these issues by making some of the channel context code require the mtx to be held rather than acquiring it, thus allowing the monitor/radar callers to keep the iflist_mtx->mtx lock ordering. While at it, also fix access to the local->scanning variable in the radar code, and document that radar_detect_enabled is now properly protected by the mtx. All this would now introduce an ABBA deadlock between the DFS work cancelling and local->mtx, so change the locking there a bit to not need to use cancel_delayed_work_sync() but be able to just use cancel_delayed_work(). The work is also safely stopped/removed when the interface is stopped, so no extra changes are needed. Reported-by: NKalle Valo <kvalo@qca.qualcomm.com> Tested-by: NSimon Wunderlich <sw@simonwunderlich.de> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 16 12月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
If we can assume that stations are never referenced by the driver after sta_state returns (and this is true since the previous iwlmvm patch and for all other drivers) then we don't need to delay station destruction, and don't need to play tricks with rcu_barrier() etc. This should speed up some scenarios like hostapd shutdown. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 02 12月, 2013 1 次提交
-
-
由 Avri Altman 提交于
There's a bug in tracking HT opmode changes in mac80211, it fails to update the driver when the channel parameters don't change. Move the code to do the HT opmode checking independently of the channel/bandwidth tracking. Signed-off-by: NAvri Altman <avri.altman@intel.com> [edit commit message] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 26 11月, 2013 4 次提交
-
-
由 Luciano Coelho 提交于
There is no reason why we should have only one channel switch announcement at a time for a single phy. When support for channel switch with multiple contexts and multiple vifs per context is implemented, we will need the chandef data for each vif. Move the csa_chandef structure to sdata to prepare for this. Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com> [Fixed compilation with mesh] Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Max Stepanov 提交于
This adds generic cipher scheme support to mac80211, such schemes are fully under control by the driver. On hw registration drivers may specify additional HW ciphers with a scheme how these ciphers have to be handled by mac80211 TX/RR. A cipher scheme specifies a cipher suite value, a size of the security header to be added to or stripped from frames and how the PN is to be verified on RX. Signed-off-by: NMax Stepanov <Max.Stepanov@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Janusz Dziedzic 提交于
To report channel width correctly we have to send correct channel parameters from mac80211 when calling cfg80211_cac_event(). This is required in case of using channel width higher than 20MHz and we have to set correct dfs channel state after CAC (NL80211_DFS_AVAILABLE). Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com> Reviewed-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Coverity points out that checking assoc_data->ie is completely useless since it's an array in the struct and can't be NULL - remove the useless checks. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 25 11月, 2013 1 次提交
-
-
由 Eliad Peller 提交于
Commit 392b9ffb ("mac80211: change beacon/connection polling") removed the IEEE80211_STA_BEACON_POLL flag. However, it accidentally removed the setting of IEEE80211_STA_CONNECTION_POLL, making the connection polling completely useless (the flag is always clear, so the result is never being checked). Fix it. Signed-off-by: NEliad Peller <eliad@wizery.com> Acked-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 28 10月, 2013 2 次提交
-
-
由 Chun-Yeow Yeoh 提交于
Refactor the channel switch IE parsing to reduce the number of function parameters. Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@cozybit.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Emmanuel Grumbach 提交于
When the driver requests to move to STATIC or DYNAMIC SMPS, we send an action frame to each associated station and reconfigure the channel context / driver. Of course, non-MIMO stations are ignored. The beacon isn't updated. The association response will include the original capabilities. Stations that associate while in non-OFF SMPS mode will get an action frame right after association to inform them about our current state. Note that we wait until the end of the EAPOL. Sending an action frame before the EAPOL is finished can be an issue for a few clients. Clients aren't likely to send EAPOL frames in MIMO anyway. When the SMPS configuration gets more permissive (e.g. STATIC -> OFF), we don't wake up stations that are asleep We remember that they don't know about the change and send the action frame when they wake up. When the SMPS configuration gets more restrictive (e.g. OFF -> STATIC), we set the TIM bit for every sleeping STA. uAPSD stations might send MIMO until they poll the action frame, but this is for a short period of time. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> [fix vht streams loop, initialisation] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 17 10月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
Some APs (notably a Sitecom WL-153 v1 with firmware 1.45) are sending invalid WMM parameters setting AIFSN, ECWmin and ECWmax to zero. The spec mandates that the value of AIFSN is at least 2, and some cards (e.g. Intel with the iwldvm driver) can't transmit when the invalid QoS parameters are actually uploaded to the firmware. Since there's little chance of being able to guess the values that the AP actually meant, disable WMM if such an invalid case is found. Since ECWmin/ECWmax are allowed to be zero, only verify AIFSN >= 2 and ECWmin <= ECWmax. Reviewed-by: NEliad Peller <eliad@wizery.com> Reported-by: NAntonio Quartulli <antonio@meshcoding.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 03 10月, 2013 1 次提交
-
-
由 Arik Nemtsov 提交于
Limit the current implementation to a single channel context used by a single vif, thereby avoiding multi-vif/channel complexities. Reuse the main function from AP CSA code, but move a portion out in order to fit the STA scenario. Add a new mac80211 HW flag so we don't break devices that don't support channel switch with channel-contexts. The new behavior will be opt-in. Signed-off-by: NArik Nemtsov <arik@wizery.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 26 9月, 2013 2 次提交
-
-
由 Simon Wunderlich 提交于
The channel switch parsing function can be re-used for the IBSS code, put the common part into an extra function. Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> [also move/rename chandef_downgrade] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Stanislaw Gruszka 提交于
Since when we detect beacon lost we do active AP probing (using nullfunc frame or probe request) there is no need to have beacon polling. Flags IEEE80211_STA_BEACON_POLL seems to be used just for historical reasons. Change also make that after we start connection poll due to beacon loss, next received beacon will abort the poll. Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 23 8月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
Seth reports that some APs, notably the Netgear WNDAP360, send invalid ECSA IEs in probe response frames with the operating class and channel number both set to zero, even when no channel switch is being done. As a result, any scan while connected to such an AP results in the connection being dropped. Fix this by ignoring any channel switch announcment in probe response frames entirely, since we're connected to the AP we will be receiving a beacon (and maybe even an action frame) if a channel switch is done, which is sufficient. Cc: stable@vger.kernel.org # 3.10 Reported-by: NSeth Forshee <seth.forshee@canonical.com> Tested-by: NSeth Forshee <seth.forshee@canonical.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 09 8月, 2013 1 次提交
-
-
由 Simon Wunderlich 提交于
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 01 8月, 2013 4 次提交
-
-
由 Johannes Berg 提交于
In case the AP has different regulatory information than we do, it can happen that we connect to an AP based on e.g. the world roaming regulatory data, and then update our database with the AP's country information disables the channel the AP is using. If this happens on an HT AP, the bandwidth tracking code will hit the WARN_ON() and disconnect. Since that's not very useful, ignore the channel-disable flag in bandwidth tracking. Cc: stable@vger.kernel.org Reported-by: NChris Wright <chrisw@sous-sol.org> Tested-by: NChris Wright <chrisw@sous-sol.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
While we're connected, the AP shouldn't change the primary channel in the HT information. We checked this, and dropped the connection if it did change it. Unfortunately, this is causing problems on some APs, e.g. on the Netgear WRT610NL: the beacons seem to always contain a bad channel and if we made a connection using a probe response (correct data) we drop the connection immediately and can basically not connect properly at all. Work around this by ignoring the HT primary channel information in beacons if we're already connected. Also print out more verbose messages in the other situations to help diagnose similar bugs quicker in the future. Cc: stable@vger.kernel.org [3.10] Acked-by: NAndy Isaacson <adi@hexapodia.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
TX status notification can get lost, or the frames could get stuck on the queue, so don't wait for the callback from the driver forever and instead time out after half a second. Cc: stable@vger.kernel.org Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Chris Wright 提交于
Commit "3d9646d0 mac80211: fix channel selection bug" introduced a possible infinite loop by moving the out target above the chandef_downgrade while loop. When we downgrade to NL80211_CHAN_WIDTH_20_NOHT, we jump back up to re-run the while loop...indefinitely. Replace goto with break and carry on. This may not be sufficient to connect to the AP, but will at least keep the cpu from livelocking. Thanks to Derek Atkins as an extra pair of debugging eyes. Cc: stable@kernel.org Signed-off-by: NChris Wright <chrisw@sous-sol.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 16 7月, 2013 2 次提交
-
-
由 Simon Wunderlich 提交于
Some regulations (like germany, but also FCC) express their transmission power limit in dBm/MHz or mW/MHz. To cope with that and be on the safe side, reduce the maximum power to half (10 MHz) or quarter (5 MHz) when operating on these reduced bandwidth channels. Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
-
由 Simon Wunderlich 提交于
The various components accessing the bitrates table must use consider the used channel bandwidth to select only available rates or calculate the bitrate correctly. There are some rates in reduced bandwidth modes which can't be represented as multiples of 500kbps, like 2.25 MBit/s in 5 MHz mode. The standard suggests to round up to the next multiple of 500kbps, just do that in mac80211 as well. Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> [make rate unsigned in ieee80211_add_tx_radiotap_header(), squash fix] Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
-
- 20 6月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
Doing so will allow us to hold the BSS (not just ref it) over the association process, thus ensuring that it doesn't time out and gets invisible to the user (e.g. in 'iw wlan0 link'.) This also fixes a leak in mac80211 where it doesn't always release the BSS struct properly in all cases where calling this function. This leak was reported by Ben Greear. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 18 6月, 2013 1 次提交
-
-
由 Simon Wunderlich 提交于
This is a collection of minor fixes: * don't allow HT IEs in IBSS for 5/10 MHz * don't allow HT IEs in Mesh for 5/10 MHz * don't downgrade from/to 5 and 10 MHz channels * don't try HT rates for 5 and 10 MHz channels when selecting rates Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 13 6月, 2013 1 次提交
-
-
由 Alexander Bondar 提交于
Track the AP's beacon rate in the scan BSS data and in the interface configuration to let the drivers know which rate the AP is using. This information may be used by drivers, in our case to let the firmware optimise beacon RX. Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 12 6月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
There are some APs, notably 2G/3G/4G Wifi routers, specifically the "Onda PN51T", "Vodafone PocketWiFi 2", "ZTE MF60" and a similar T-Mobile branded device [1] that erroneously don't include all the needed information in (re)association response frames. Work around this by assuming the information is the same as it was in the beacon or probe response and using the data from there instead. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=58881. [1] https://bbs.archlinux.org/viewtopic.php?pid=1277305 Note that this requires marking the first ieee802_11_parse_elems() argument const, otherwise we'd get a compiler warning. Cc: stable@vger.kernel.org Reported-and-tested-by: NMichal Zajac <manwe@manwe.pl> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 05 6月, 2013 2 次提交
-
-
由 Alexander Bondar 提交于
Currently beacon availability upon association is marked by have_beacon flag of assoc_data structure that becomes unavailable when association completes. However beacon availability indication is required also after association to inform a driver. Currently dtim_period parameter is used for this purpose. Move have_beacon flag to another structure, persistant throughout a interface's life cycle. Use suitable sematics for beacon availability indication. Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com> [fix another instance of BSS_CHANGED_DTIM_PERIOD in docs] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Alexander Bondar 提交于
ieee80211_rx_bss_info() deals with dtim_period setting and PS update when associated. Move all these to another locations cleaning this function. Also, the current implementation is buggy because when it calls ieee80211_recalc_ps() bss_conf->dtim_period is notset properly yet and thus nothing will happen. Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 04 6月, 2013 2 次提交
-
-
由 Johannes Berg 提交于
Do some cleanups in the cfg80211 SME APIs, which are only used by mac80211. Most of these functions get a frame passed, and there isn't really any reason to export multiple functions as cfg80211 can check the frame type instead, do that. Additionally, the API functions have confusing names like cfg80211_send_...() which was meant to indicate that it sends an event to userspace, but gets a bit confusing when there's both TX and RX and they're not all clearly labeled. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Pontus Fuchs 提交于
The connection monitor needs to know the tx status of nullframes to work properly. Signed-off-by: NPontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 25 5月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
Using separate locks in cfg80211 and mac80211 has always caused issues, for example having to unlock in places in mac80211 to call cfg80211, which even needed a framework to make cfg80211 calls after some functions returned etc. Additionally, I suspect some issues people have reported with the cfg80211 state getting confused could be due to such issues, when cfg80211 is asking mac80211 to change state but mac80211 is in the process of telling cfg80211 that the state changed (in another way.) Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 17 5月, 2013 6 次提交
-
-
由 Stanislaw Gruszka 提交于
We send direct probe to broadcast address, as some APs do not respond to unicast PROBE frames when unassociated. Broadcast frames are not acked, so we can not use that for trigger MLME state machine, but we need to use old timeout mechanism. This fixes authentication timed out like below: [ 1024.671974] wlan6: authenticate with 54:e6:fc:98:63:fe [ 1024.694125] wlan6: direct probe to 54:e6:fc:98:63:fe (try 1/3) [ 1024.695450] wlan6: direct probe to 54:e6:fc:98:63:fe (try 2/3) [ 1024.700586] wlan6: send auth to 54:e6:fc:98:63:fe (try 3/3) [ 1024.701441] wlan6: authentication with 54:e6:fc:98:63:fe timed out With fix, we have: [ 4524.198978] wlan6: authenticate with 54:e6:fc:98:63:fe [ 4524.220692] wlan6: direct probe to 54:e6:fc:98:63:fe (try 1/3) [ 4524.421784] wlan6: send auth to 54:e6:fc:98:63:fe (try 2/3) [ 4524.423272] wlan6: authenticated [ 4524.423811] wlan6: associate with 54:e6:fc:98:63:fe (try 1/3) [ 4524.427492] wlan6: RX AssocResp from 54:e6:fc:98:63:fe (capab=0x431 status=0 aid=1) Cc: stable@vger.kernel.org # 3.9 Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Alexander Bondar 提交于
Generally, the DTIM period is available after a beacon has been received, and if no beacon has been received enabling powersave is problematic anyway for synchronisation. Since some drivers may require the DTIM period for powersave, don't enable powersave until it becomes available in case the scan/association managed to not receive a beacon. Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
When an HT AP is advertising channel switch in a beacon, it doesn't (and shouldn't, according to 802.11-2012 Table 8-20) include a secondary channel offset element. The only possible interpretation is that the previous secondary channel offset remains valid, so use that when switching channel based only on beacon information. VHT requires the Wide Bandwidth Channel Switch subelement to be present in the Channel Switch Wrapper element, so the code for that is probably ok (see 802.11ac Draft 4, 8.4.2.165.) Reported-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Even if the frame isn't transmitted to the AP, we need to report it to cfg80211 so the state there can be updated correctly. Reported-by: NJouni Malinen <j@w1.fi> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
When an HT AP is advertising channel switch in a beacon, it doesn't (and shouldn't, according to 802.11-2012 Table 8-20) include a secondary channel offset element. The only possible interpretation is that the previous secondary channel offset remains valid, so use that when switching channel based only on beacon information. VHT requires the Wide Bandwidth Channel Switch subelement to be present in the Channel Switch Wrapper element, so the code for that is probably ok (see 802.11ac Draft 4, 8.4.2.165.) Reported-by: NSujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Since commit 12e7f517, IEEE80211_SDATA_DISCONNECT_RESUME no longer worked as it would simply never be tested. Restore a bit of the code removed there and in 9b7d72c1 to make it work again. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-