- 15 2月, 2013 26 次提交
-
-
由 Thomas Pedersen 提交于
Previously, the entire mesh beacon would be generated each time the beacon timer fired. Instead generate a beacon head and tail (so the TIM can easily be inserted when mesh power save is on) when starting a mesh or the MBSS parameters change. Also add a mutex for protecting beacon updates and preventing leaks. Signed-off-by: NThomas Pedersen <thomas@cozybit.com> 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 提交于
For HT and VHT the current bandwidth can change, add the function ieee80211_vif_change_bandwidth() to take care of this. It returns a failure if the new bandwidth isn't compatible with the existing channel context, the caller has to handle that. When it happens, also inform the driver that the bandwidth changed for this virtual interface (no drivers would actually care today though.) Changing to/from HT/VHT isn't allowed though. 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 提交于
This should be called ieee80211_change_chanctx() since it changes the channel context, not a chandef. 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 提交于
Handle the operating mode notification action frame. When the supported streams or the bandwidth change let the driver and rate control algorithm know. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
With VHT, a station can change the number of spatial streams it can receive on the fly, not unlike spatial multiplexing in HT. Prepare for that by tracking the maximum number of spatial streams it can receive when the connection is established. 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 提交于
Since no driver calls the TKIP functions from interrupt context, there's no need to use spin_lock_irqsave(). Just use spin_lock_bh() (and spin_lock() in the TX path where we're in a BH or they're already disabled.) Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
There's no need to use _irqsave() as the lock is never used in interrupt context. This also fixes a problem in the iwlwifi MVM driver that calls spin_unlock_bh() within its set_tim() callback. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
There's no use for it, WPA is entirely handled in wpa_supplicant in userspace, so don't pick the IE. 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 提交于
Since the idle decision rework, mac80211 started calling bss_info_changed() for the driver's monitor interface, which causes a crash for iwlwifi, but drivers generally don't expect this to happen. Therefore, avoid it. While at it, also prevent calling it in such cases and only print a warning. For the P2P Device interface the idle will no longer be called (no channel context), so also prevent that and warn on it. Reported-by: NChaitanya <chaitanya.mgit@gmail.com> 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>
-
由 Thomas Pedersen 提交于
A few mesh utility functions will call ieee80211_bss_info_change_notify(), and then the caller might notify the driver of the same change again. Avoid this redundancy by propagating the BSS changes and generally calling bss_info_change_notify() once per change. Signed-off-by: NThomas Pedersen <thomas@cozybit.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Michael Braun 提交于
When sending a broadcast while at least on of the connected stations is sleeping, it gets queued and send after a DTIM beacon is sent. If the packet was to be sent on a vlan interface, the vif used for dequeing from the per-bss queue does not hold the per-vlan sdata. The correct sdata is required to use the correct per-vlan broadcast/multicast key. This patch fixes this by restoring the per-vlan sdata using the skb->dev entry. Signed-off-by: NMichael Braun <michael-dev@fami-braun.de> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Michael Braun 提交于
When the vlan device is removed, ps->bc_buf processing can no longer send its frames. Signed-off-by: NMichael Braun <michael-dev@fami-braun.de> 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>
-
- 13 2月, 2013 1 次提交
-
-
由 Felix Fietkau 提交于
When MCS rates start to get bad in 2.4 GHz because of long range or strong interference, CCK rates can be a lot more robust. This patch adds a pseudo MCS group containing CCK rates (long preamble in the lower 4 slots, short preamble in the upper slots). Signed-off-by: NFelix Fietkau <nbd@openwrt.org> [make minstrel_ht_get_stats static] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 12 2月, 2013 13 次提交
-
-
由 Emmanuel Grumbach 提交于
Bail out if no update is made to the SMPS state. This allows the driver to avoid duplicating the state. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Seth Forshee 提交于
We've got a couple of races when enabling powersave with an AP for off-channel operation. The first is fairly simple. If we go off-channel before the nullfunc frame to enable PS is transmitted then it may not be received by the AP. Add a flush after enabling off-channel PS to prevent this from happening. The second race is a bit more subtle. If the driver supports QoS and has frames queued when the nullfunc frame is queued, those frames may get transmitted after the nullfunc frame. If PM is not set then the AP is being told that we've exited PS before we go off-channel and may try to deliver frames. To prevent this, add a flush after stopping the queues but before passing the nullfunc frame to the driver. Signed-off-by: NSeth Forshee <seth.forshee@canonical.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 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>
-
由 Felix Fietkau 提交于
It's more of an unnecessary micro-optimization and it prevents switching from long-GI to short-GI in HT20/single-stream for the lowest rate Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Felix Fietkau 提交于
Signed-off-by: NFelix Fietkau <nbd@openwrt.org> 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 提交于
There are only a few drivers that use HW scan, and all of those don't need a non-idle transition before starting the scan -- some don't even care about idle at all. Remove the flag and code associated with it. The only driver that really actually needed this is wl1251 and it can just do it itself in the hw_scan callback -- implement that. Acked-by: NLuciano Coelho <coelho@ti.com> 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>
-
由 Alexander Bondar 提交于
Add debugfs driver callbacks so drivers can add debugfs entries for interfaces. Note that they _must_ remove the entries again as add/remove in the driver doesn't correspond to add/remove in debugfs; the former is up/down while the latter is netdev create/destroy. Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com> Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Currently the code assigns channel contexts to VLANs (for use by the TX/RX code) when the AP master gets its channel context assigned. This works fine, but in the upcoming radar detection work the VLANs don't require a channel context (during radar detection) and assigning one to them anyway causes issues with locking and also inconsistencies -- a VLAN interface that is added before radar detection would get the channel context, while one added during it wouldn't. Fix these issues moving the channel context copying to a new explicit operation that will not be used in the radar detection code. Acked-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-