- 22 3月, 2013 3 次提交
-
-
由 Janusz Dziedzic 提交于
Add P2P NoA settings for STA mode. Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com> [fix docs] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Janusz Dziedzic 提交于
Use ieee80211_p2p_noa_attr structure during P2P_PS (oppps) detection. Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Ben Greear 提交于
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: NBen Greear <greearb@candelatech.com> [add the number of beacons to the message] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 19 3月, 2013 2 次提交
-
-
由 Johannes Berg 提交于
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: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
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: NJohannes Berg <johannes.berg@intel.com>
-
- 06 3月, 2013 2 次提交
-
-
由 Stanislaw Gruszka 提交于
Remove not used any longer suspend/resume code. Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Support the cfg80211 API to override VHT capabilities on association. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 02 3月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
The VHT MCSes we advertise to the AP were supposed to be restricted to the AP, but due to a bug in the logic mac80211 will advertise rates to the AP that aren't even supported by the local device. To fix this skip any adjustment if the NSS isn't supported at all. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 27 2月, 2013 2 次提交
-
-
由 Ben Greear 提交于
Some mlme work structs are not cancelled on disassociation nor interface deletion, which leads to them running after the memory has been freed There is not a clean way to cancel these in the disassociation logic because they must be canceled outside of the ifmgd->mtx lock, so just cancel them in mgd_stop logic that tears down the station. This fixes the crashes we see in 3.7.9+. The crash stack trace itself isn't so helpful, but this warning gives more useful info: WARNING: at /home/greearb/git/linux-3.7.dev.y/lib/debugobjects.c:261 debug_print_object+0x7c/0x8d() ODEBUG: free active (active state 0) object type: work_struct hint: ieee80211_sta_monitor_work+0x0/0x14 [mac80211] Modules linked in: [...] Pid: 14743, comm: iw Tainted: G C O 3.7.9+ #11 Call Trace: [<ffffffff81087ef8>] warn_slowpath_common+0x80/0x98 [<ffffffff81087fa4>] warn_slowpath_fmt+0x41/0x43 [<ffffffff812a2608>] debug_print_object+0x7c/0x8d [<ffffffff812a2bca>] debug_check_no_obj_freed+0x95/0x1c3 [<ffffffff8114cc69>] slab_free_hook+0x70/0x79 [<ffffffff8114ea3e>] kfree+0x62/0xb7 [<ffffffff8149f465>] netdev_release+0x39/0x3e [<ffffffff8136ad67>] device_release+0x52/0x8a [<ffffffff812937db>] kobject_release+0x121/0x158 [<ffffffff81293612>] kobject_put+0x4c/0x50 [<ffffffff8148f0d7>] netdev_run_todo+0x25c/0x27e Cc: stable@vger.kernel.org Signed-off-by: NBen Greear <greearb@candelatech.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Ben Greear 提交于
Re-order the quiesce code so that timers are always stopped before work-items are flushed. This was not the problem I saw, but I think it may still be more correct. Signed-off-by: NBen Greear <greearb@candelatech.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 15 2月, 2013 15 次提交
-
-
由 Johannes Berg 提交于
Even when connecting to an AP that doesn't support VHT, and even when the local device doesn't support it either, the downgrade message gets printed. Suppress the message if HT and/or VHT is disabled. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Make all the parsed IE pointers const, and propagate the change to all the users etc. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
A while ago, I made the mac80211 station code never change the channel type after association. This solved a number of issues but is ultimately wrong, we should react if the AP changes the HT operation IE and switches bandwidth. One of the issues is that we associate as HT40 capable, but if the AP ever switches to 40 MHz we won't be able to receive such frames because we never set our channel to 40 MHz. This addresses this and VHT operation changes. If there's a change that is incompatible with our setup, e.g. if the AP decides to change the channel entirely (and for some reason we still hear the beacon) we'll just disconnect. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The next patch will need it further up in the file, so move it unchanged now. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The channel use is confusing, some uses the channel context and some the bss_conf.chandef. The latter is fine, so get rid of the channel context part. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Having HT/VHT operation IEs but not capability IEs leads to a strange situation where we configure the channel to an HT or VHT bandwidth and then can't actually use it. Prevent this by checking that the HT and VHT capability IEs are present as well as the operation IEs; if not, disable HT and/or VHT. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
In beacons and association response frames an AP may include an operating mode notification element to advertise changes in the number of spatial streams it can receive. Handle this using the existing function that handles the action frame, but only handle NSS changes, not bandwidth changes which aren't allowed here. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The code to disable HT and VHT if VHT was advertised without VHT is wrong -- it accidentally uses the wrong flags. Fix that. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
In case of connection, the station data is initialised from the beacon/probe response first and then updated from the association response. If the latter is different we update the rate control algorithm and driver. Instead of doing it this way, set the station data properly with data from the association response before initializing rate control. Also simplify the code by passing the station pointer. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
For VHT, many more bandwidth changes are possible. As a first step, stop toggling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 flag in the HT capabilities and instead introduce a bandwidth field indicating the currently usable bandwidth to transmit to the station. Of course, make all drivers use it. To achieve this, make ieee80211_ht_cap_ie_to_sta_ht_cap() get the station as an argument, rather than the new capabilities, so it can set up the new bandwidth field. If the station is a VHT station and VHT bandwidth is in use, also set the bandwidth accordingly. Doing this allows us to get rid of the supports_40mhz flag as the HT capabilities now reflect the true capability instead of the current setting. While at it, also fix ieee80211_ht_cap_ie_to_sta_ht_cap() to not ignore HT cap overrides when MCS TX isn't supported (not that it really happens...) Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Like with HT, make things a bit simpler in future patches by passing the station to ieee80211_vht_cap_ie_to_sta_vht_cap() instead of the vht_cap pointer. Also disable VHT here if HT isn't supported. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
In some cases when disconnecting after (or during?) CSA the queues might not recover, and then the only way to recover is reloading the module. Fix this by always unblocking the queue CSA reason when disconnecting. Cc: stable@vger.kernel.org Reported-by: NJan-Michael Brummer <jan.brummer@tabos.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
In my commit 1672c0e3 ("mac80211: start auth/assoc timeout on frame status") I broke auth/assoc timeout handling: in case we wait for the TX status, it now leaves the timeout field set to 0, which is a valid time and can compare as being before now ("jiffies"). Thus, if the work struct runs for some other reason, the auth/assoc is treated as having timed out. Fix this by introducing a separate "timeout_started" variable that tracks whether the timeout has started and is checked before timing out. Additionally, for proper TX status handling the change requires that the skb->dev pointer is set up for all the frames, so set it up for all frames in mac80211. Reported-by: NWojciech Dubowik <Wojciech.Dubowik@neratec.com> Tested-by: NWojciech Dubowik <Wojciech.Dubowik@neratec.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Wojciech Dubowik 提交于
Function ieee80211_sta_reset_conn_monitor has been resetting probe_send_count too early and nullfunc check was never called after succesfull ack. Reported-by: NMagnus Cederlöf <mcider@gmail.com> Tested-by: NMagnus Cederlöf <mcider@gmail.com> Signed-off-by: NWojciech Dubowik <Wojciech.Dubowik@neratec.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Simon Wunderlich 提交于
Add command to trigger radar detection in the driver/FW. Once radar detection is started it should continuously monitor for radars as long as the channel active. If radar is detected usermode notified with 'radar detected' event. Scanning and remain on channel functionality must be disabled while doing radar detection/scanning, and vice versa. Based on original patch by Victor Goldenshtein <victorg@ti.com> Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 12 2月, 2013 8 次提交
-
-
由 Seth Forshee 提交于
Scans currently work by stopping the netdev tx queues but leaving the mac80211 queues active. This stops the flow of incoming packets while still allowing mac80211 to transmit nullfunc and probe request frames to facilitate scanning. However, the driver may try to wake the mac80211 queues while in this state, which will also wake the netdev queues. To prevent this, add a new queue stop reason, IEEE80211_QUEUE_STOP_REASON_OFFCHANNEL, to be used when stopping the tx queues for off-channel operation. This prevents the netdev queues from waking when a driver wakes the mac80211 queues. This also stops all frames from being transmitted, even those meant to be sent off-channel. Add a new tx control flag, IEEE80211_TX_CTL_OFFCHAN_TX_OK, which allows frames to be transmitted when the queues are stopped only for the off-channel stop reason. Update all locations transmitting off-channel frames to use this flag. Signed-off-by: NSeth Forshee <seth.forshee@canonical.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
When we get to association, the AP station already exists and is marked authenticated, so moving it into IEEE80211_STA_AUTH again is a NOP, remove it. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Now that we have channel contexts, idle is (pretty much) equivalent to not having a channel context. Change the code to use this relation so that there no longer is a need for a lot of idle recalculate calls everywhere. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The functions were added for some sort of Bluetooth coexistence, but aren't used, so remove them again. Reviewed-by: NLuciano Coelho <coelho@ti.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
In order to be able to predict the next DTIM TBTT in the driver, add the ability to use timing data from beacons only with the new hardware flag IEEE80211_HW_TIMING_BEACON_ONLY and the BSS info value sync_dtim_count which is only valid if the timing data came from a beacon. The data can only come from a beacon, and if no beacon was received before association it is updated later together with the DTIM count notification. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
While technically the TSF isn't an IE, it can be necessary to distinguish between the TSF from a beacon and a probe response, in particular in order to know the next DTIM TBTT, as not all APs are spec compliant wrt. TSF==0 being a DTIM TBTT and thus the DTIM count needs to be taken into account as well. To allow this, move the TSF into the IE struct so it can be known whence it came. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The messages currently refer to probe request probes, but on some devices null data packets will be used instead. Make the messages more generic. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
This prepares for using the spinlock instead of krefs which is needed in the next patch to track the refs of combined BSSes correctly. Acked-by: Bing Zhao <bzhao@marvell.com> [mwifiex] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 11 2月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
When trying to connect to an AP that advertises HT but not VHT, the mac80211 code erroneously uses the configuration from the AP as is instead of checking it against regulatory and local capabilities. This can lead to using an invalid or even inexistent channel (like 11/HT40+). Additionally, the return flags from downgrading must be ORed together, to collect them from all of the downgrades. Also clarify the message. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 08 2月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
My commit f2d9d270 ("mac80211: support VHT association") introduced a very stupid bug: the loop to downgrade the channel width never attempted to actually use it again so it would downgrade all the way to 20_NOHT. Fix it. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 05 2月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
If the driver determined the connection was lost or that it couldn't securely maintain the connection when coming out of WoWLAN, send a deauth frame to the AP to also let it know. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 04 2月, 2013 2 次提交
-
-
由 Johannes Berg 提交于
With multi-channel, there's a corner case where a driver doesn't receive a beacon soon enough to be able to sync its timers with the AP. In this case, the only recovery (after trying again) is to disconnect from the AP. Allow calling ieee80211_connection_loss() for such cases. To make that possible, modify the work function to not rely on the IEEE80211_HW_CONNECTION_MONITOR flag but use new state kept in the interface instead. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
If the driver determines the connection is lost, send a deauth frame to the AP anyway just in case it still considers the connection alive. The frame might not go through, but at least we've tried. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 31 1月, 2013 2 次提交
-
-
由 Johannes Berg 提交于
When sending authentication/association frames they might take a bit of time to go out because we may have to synchronise with the AP, in particular in the case where it's really a P2P GO. In this case the 200ms fixed timeout could potentially be too short if the beacon interval is relatively large. For drivers that report TX status we can do better. Instead of starting the timeout directly, start it only when the frame status arrives. Since then the frame was out on the air, we can wait shorter (the typical response time is supposed to be 30ms, wait 100ms.) Also, if the frame failed to be transmitted try again right away instead of waiting. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Emmanuel Grumbach 提交于
Currently, when the driver requires the DTIM period, mac80211 will wait to hear a beacon before association. This behavior is suboptimal since some drivers may be able to deal with knowing the DTIM period after the association, if they get it at all. To address this, notify the drivers with bss_info_changed with the new BSS_CHANGED_DTIM_PERIOD flag when the DTIM becomes known. This might be when changing to associated, or later when the entire association was done with only probe response information. Rename the hardware flag for the current behaviour to IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC to more accurately reflect its behaviour. IEEE80211_HW_NEED_DTIM_PERIOD is no longer accurate as all drivers get the DTIM period now, just not before association. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-