summaryrefslogtreecommitdiffstats
path: root/net/mac80211/mlme.c
Commit message (Collapse)AuthorAgeFilesLines
...
| * mac80211: don't wait for TX status foreverJohannes Berg2013-07-311-3/+12
| | | | | | | | | | | | | | | | | | | | 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: Johannes Berg <johannes.berg@intel.com>
| * mac80211: fix infinite loop in ieee80211_determine_chantypeChris Wright2013-07-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit "3d9646d 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: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | cfg80211/mac80211: use reduced txpower for 5 and 10 MHzSimon Wunderlich2013-07-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | 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: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
* | mac80211: select and adjust bitrates according to channel modeSimon Wunderlich2013-07-161-41/+54
|/ | | | | | | | | | | | | | | | 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: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> [make rate unsigned in ieee80211_add_tx_radiotap_header(), squash fix] Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
* cfg80211: require passing BSS struct back to cfg80211_assoc_timeoutJohannes Berg2013-06-191-8/+7
| | | | | | | | | | | | 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: Johannes Berg <johannes.berg@intel.com>
* Merge remote-tracking branch 'mac80211/master' into HEADJohannes Berg2013-06-191-7/+80
|\ | | | | | | | | | | | | | | | | | | | | Merge mac80211 to avoid conflicts with the nl80211 attrbuf changes. Conflicts: net/mac80211/iface.c net/wireless/nl80211.c Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: work around broken APs not including HT infoJohannes Berg2013-06-121-7/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Michal Zajac <manwe@manwe.pl> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: fix various components for the new 5 and 10 MHz widthsSimon Wunderlich2013-06-181-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | 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: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: track AP's beacon rate and give it to the driverAlexander Bondar2013-06-131-1/+7
| | | | | | | | | | | | | | | | | | | | 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: Alexander Bondar <alexander.bondar@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: Use suitable semantics for beacon availability indicationAlexander Bondar2013-06-051-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Alexander Bondar <alexander.bondar@intel.com> [fix another instance of BSS_CHANGED_DTIM_PERIOD in docs] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: fix powersave bug and clean up ieee80211_rx_bss_infoAlexander Bondar2013-06-051-21/+9
| | | | | | | | | | | | | | | | | | | | | | 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: Alexander Bondar <alexander.bondar@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | cfg80211/mac80211: clean up cfg80211 SME APIsJohannes Berg2013-06-041-21/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Johannes Berg <johannes.berg@intel.com>
* | mac80211: set IEEE80211_TX_CTL_REQ_TX_STATUS on nullframesPontus Fuchs2013-06-041-0/+4
| | | | | | | | | | | | | | | | The connection monitor needs to know the tx status of nullframes to work properly. Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | cfg80211/mac80211: use cfg80211 wdev mutex in mac80211Johannes Berg2013-05-251-223/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Johannes Berg <johannes.berg@intel.com>
* | Merge remote-tracking branch 'mac80211/master' into mac80211-nextJohannes Berg2013-05-251-10/+35
|\ \ | |/
| * mac80211: fix direct probe authStanislaw Gruszka2013-05-171-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: report deauth to cfg80211 for local state changeJohannes Berg2013-05-161-4/+4
| | | | | | | | | | | | | | | | | | 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: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: fix HT beacon-based channel switch handlingJohannes Berg2013-05-161-6/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: fix IEEE80211_SDATA_DISCONNECT_RESUMEJohannes Berg2013-05-161-0/+25
| | | | | | | | | | | | | | | | | | | | Since commit 12e7f517029dad819c45eca9ca01fdb9ba57616b, IEEE80211_SDATA_DISCONNECT_RESUME no longer worked as it would simply never be tested. Restore a bit of the code removed there and in 9b7d72c1041ec5b20b24af487a9 to make it work again. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: enable power save only if DTIM period is availableAlexander Bondar2013-05-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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: Alexander Bondar <alexander.bondar@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: fix HT beacon-based channel switch handlingJohannes Berg2013-05-161-6/+22
|/ | | | | | | | | | | | | | | | 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: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge branch 'master' of ↵John W. Linville2013-04-231-4/+20
|\ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless Conflicts: drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
| * mac80211: fix cfg80211 interaction on auth/assoc requestJohannes Berg2013-04-101-4/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If authentication (or association with FT) is requested by userspace, mac80211 currently doesn't tell cfg80211 that it disconnected from the AP. That leaves inconsistent state: cfg80211 thinks it's connected while mac80211 thinks it's not. Typically this won't last long, as soon as mac80211 reports the new association to cfg80211 the old one goes away. If, however, the new authentication or association doesn't succeed, then cfg80211 will forever think the old one still exists and will refuse attempts to authenticate or associate with the AP it thinks it's connected to. Anders reported that this leads to it taking a very long time to reconnect to a network, or never even succeeding. I tested this with an AP hacked to never respond to auth frames, and one that works, and with just those two the system never recovers because one won't work and cfg80211 thinks it's connected to the other so refuses connections to it. To fix this, simply make mac80211 tell cfg80211 when it is no longer connected to the old AP, while authenticating or associating to a new one. Cc: stable@vger.kernel.org Reported-by: Anders Kaseorg <andersk@mit.edu> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: indicate admission control in TX queue parametersAlexander Bondar2013-04-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Some driver implementations need to know whether mandatory admission control is required by the AP for some ACs. Add a parameter to the TX queue parameters indicating this. As there's currently no support for admission control in mac80211's AP implementation, it's only ever set for the client implementation. Signed-off-by: Alexander Bondar <alexander.bondar@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | Merge remote-tracking branch 'wireless-next/master' into mac80211-nextJohannes Berg2013-04-221-2/+4
|\ \
| * \ Merge branch 'for-john' of ↵John W. Linville2013-04-101-62/+66
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Conflicts: drivers/net/wireless/ath/carl9170/debug.c drivers/net/wireless/ath/carl9170/main.c net/mac80211/ieee80211_i.h
| * \ \ Merge branch 'master' of ↵John W. Linville2013-03-291-2/+4
| |\ \ \ | | | |/ | | |/| | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless Conflicts: net/mac80211/sta_info.c net/wireless/core.h
| | * | mac80211: Don't restart sta-timer if not associated.Ben Greear2013-03-241-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I found another crash when deleting lots of virtual stations in a congested environment. I think the problem is that the ieee80211_mlme_notify_scan_completed could call ieee80211_restart_sta_timer for a stopped interface that was about to be deleted. With the following patch I am unable to reproduce the crash. Signed-off-by: Ben Greear <greearb@candelatech.com> [move check, also make the same change in mesh] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | | mac80211: remove warning from ieee80211_beacon_lossAlexander Bondar2013-04-161-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, mac80211 assumes that connection monitor offload for BSS station implies that the device: - sends periodic keep alive packets to associated AP - monitors missed beacons - actively probes the AP in case of missed beacons In case of poor connection conditions it expects the function ieee80211_connection_loss() to be called by driver. However, some devices implement connection monitor offload excluding active AP probing. To allow them to call ieee80211_beacon_loss() cleanly, remove the warning there and thus allow them to use mac80211 for the AP probing even if connection monitor offload is supported. Signed-off-by: Alexander Bondar <alexander.bondar@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | | mac80211: handle wide bandwidth channel switchJohannes Berg2013-04-161-17/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Parse and react to the wide bandwidth channel switch element in beacons/action frames. Finding the element was done in a previous patch (it has different positions in beacons/action frames), now handle it. If there's something wrong with it simply disconnect. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | | mac80211: parse VHT channel switch IEsJohannes Berg2013-04-161-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VHT introduces multiple IEs that need to be parsed for a wide bandwidth channel switch. Two are (currently) needed in mac80211: * wide bandwidth channel switch element * channel switch wrapper element The former is contained in the latter for beacons and probe responses, but not for the spectrum management action frames so the IE parser needs a new argument to differentiate them. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | | mac80211: handle extended channel switch announcementJohannes Berg2013-04-161-4/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Handle the (public) extended channel switch announcement action frames. Parts of the data in these frames isn't really in IEs, but put it into the elems struct anyway to simplify the handling. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | | mac80211: support secondary channel offset in CSAJohannes Berg2013-04-161-15/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for the secondary channel offset IE in channel switch announcements. This is necessary for proper handling of CSA on HT access points. For this to work it is also necessary to convert everything here to use chandef structs instead of just channels. The driver updates aren't really correct though. In particular, the TI wl18xx driver update can't possibly be right since it just ignores the new channel width for lack of firmware API. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | | mac80211: support extended channel switchJohannes Berg2013-04-161-26/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support extended channel switch when the operating class is one of the global operating classes as defined in Annex E of 802.11-2012. If it isn't, disconnect from the AP instead. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | | mac80211: unify CSA action frame/beacon processingJohannes Berg2013-04-161-28/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CSA action frame content should be processed as variable IEs rather than fixed to make it extensible. Unify the code and process them just like CSA in beacons to make it easier to extend for HT/VHT. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | | mac80211: use second center_freq segment only in 80+80Johannes Berg2013-04-161-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The field is otherwise reserved, so we shouldn't read and reject it, though any sane system will probably have to set it to 0 anyway. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | | mac80211: always advertise STBC/MCSes even if no AP supportJohannes Berg2013-04-101-32/+0
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | Advertise STBC capabilities and MCS rates even if the AP doesn't support them. This has always been the right thing to do, but used to be problematic with some APs. Now WFA testing requires this so re-enable it, problematic APs would then presumably not pass the test and be fixed. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: don't fiddle with netdev queues in MLME codeJohannes Berg2013-04-081-24/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The netdev queues should always represent the state that the driver gave them, so fiddling with them isn't really appropriate in the mlme code. Also, since we stop queues for flushing now, this really isn't necessary any more. As the scan/offchannel code has also been modified to no longer do this a while ago, remove the outdated smp_mb() and comments about it. While at it, also add a pair of braces that was missing. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: disable uAPSD if all ACs are under ACMAlexander Bondar2013-04-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's unlikely that an AP requires WMM mandatory admission control for all access categories, and if it does then we still transmit on the background AC without requesting admission. However, avoid using uAPSD in this case since the implementation could run into issues and might use other ACs etc. Signed-off-by: Alexander Bondar <alexander.bondar@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: parse Timeout Interval Element using a structJohannes Berg2013-04-081-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Instead of open-coding the accesses and length check do the length check in the IE parser and assign a struct pointer for use in the remaining code. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: check ERP info IE length in parserJohannes Berg2013-04-081-1/+1
| | | | | | | | | | | | | | | | | | | | | It's always just one byte, so check for that and remove the length field from the parser struct. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: check DSSS params IE length in parserJohannes Berg2013-04-081-1/+1
| | | | | | | | | | | | | | | | | | | | | It's always just one byte, so check for that and remove the length field from the parser struct. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: be more careful about sending beacon-loss-eventsBen Greear2013-04-081-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | I don't think we should send the events unless it was actually a beacon that was lost...not just any probe of an AP. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: Use a cfg80211_chan_def in ieee80211_hw_conf_chanKarl Beldan2013-03-251-7/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drivers that don't use chanctxes cannot perform VHT association because they still use a "backward compatibility" pair of {ieee80211_channel, nl80211_channel_type} in ieee80211_conf and ieee80211_local. Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com> [fix kernel-doc] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: allow drivers to set default uAPSD parametersAlexander Bondar2013-03-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mac80211 currently sets uAPSD parameters to have VO AC trigger- and delivery-enabled, with maximum service period length. Allow drivers to change these default settings since different uAPSD client implementations may handle errors differently and be able to recover from some errors. Note: some APs may not function correctly if one or all ACs are trigger- and delivery-enabled, see http://thread.gmane.org/gmane.linux.kernel.wireless.general/93577. We retested with this AP and later firmware doesn't have this bug any more. Signed-off-by: Alexander Bondar <alexander.bondar@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: add P2P NoA settingsJanusz Dziedzic2013-03-221-20/+25
| | | | | | | | | | | | | | | | | | | | | | | | Add P2P NoA settings for STA mode. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> [fix docs] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: use ieee80211_p2p_noa_attr structureJanusz Dziedzic2013-03-221-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | Use ieee80211_p2p_noa_attr structure during P2P_PS (oppps) detection. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | | mac80211: make beacon-loss-count configurableBen Greear2013-03-221-3/+7
|/ / | | | | | | | | | | | | | | | | | | | | | | On loaded systems with lots of VIFs, I see lots of beacon timeouts, even though the connection to the AP is very good. Allow tuning the beacon-loss-count variable to give the system longer to process beacons if the user prefers. Signed-off-by: Ben Greear <greearb@candelatech.com> [add the number of beacons to the message] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: stop queues temporarily for flushingJohannes Berg2013-03-181-0/+4
| | | | | | | | | | | | | | | | | | | | Sometimes queues are flushed in the middle of operation, which can lead to driver issues. Stop queues temporarily, while flushing, to avoid transmitting new packets while they are being flushed. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: pass queue bitmap to flush operationJohannes Berg2013-03-181-4/+4
| | | | | | | | | | | | | | | | | | | | There are a number of situations in which mac80211 only really needs to flush queues for one virtual interface, and in fact during this frames might be transmitted on other virtual interfaces. Calculate and pass a queue bitmap to the driver so it knows which queues to flush. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
OpenPOWER on IntegriCloud