- 19 6月, 2012 1 次提交
-
-
由 Arik Nemtsov 提交于
While HW reconfig is in progress, drop all incoming Rx. This prevents incoming packets from changing the internal state of the driver or calling callbacks of the low level driver while it is in inconsistent state. Signed-off-by: NArik Nemtsov <arik@wizery.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 18 6月, 2012 4 次提交
-
-
由 Chun-Yeow Yeoh 提交于
This patch fixes the wrong assignment of mesh element TTL. Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Chun-Yeow Yeoh 提交于
As defined in section 13.10.9.3 Case D (802.11-2012), this control variable is used to limit the mesh STA to send only one PREQ to a root mesh STA within this interval of time (in TUs). The default value for this variable is set to 2000 TUs. However, for current implementation, the maximum configurable of dot11MeshHWMPconfirmationInterval is restricted by dot11MeshHWMPactivePathTimeout. Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com> [line-break commit log] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Chun-Yeow Yeoh 提交于
mesh_path_root_timer is invoked once the dot11MeshHWMPRootMode is larger than 1. This patch also adds the backward compatible to the previous setting on dot11MeshHWMPRootMode. If the user configures as follow, it will still trigger the proactive RANN with Gate Announcement. iw mesh0 set mesh_param mesh_hwmp_rootmode 1 iw mesh0 set mesh_param mesh_gate_announcements 1 similar to the following setting: iw mesh0 set mesh_param mesh_hwmp_rootmode 4 iw mesh0 set mesh_param mesh_gate_announcements 1 Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com> [line-break commit log] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Chun-Yeow Yeoh 提交于
Generate the proactive PREP element in Proactive PREQ mode as defined in Sec. 13.10.10.3 (Case D) of IEEE Std. 802.11-2012. Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 14 6月, 2012 2 次提交
-
-
由 Chun-Yeow Yeoh 提交于
Generate the proactive PREQ element as defined in Sec. 13.10.9.3 (Case C) of IEEE Std. 802.11-2012 based on the selection of dot11MeshHWMPRootMode as follow: dot11MeshHWMPRootMode (2) is proactivePREQnoPREP dot11MeshHWMPRootMode (3) is proactivePREQwithPREP The proactive PREQ is generated based on the interval defined by dot11MeshHWMProotInterval. With this change, proactive RANN element is now generated if the dot11MeshHWMPRootMode is set to (4) instead of (1). Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com> [line-break commit log] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Chun-Yeow Yeoh 提交于
Add the mesh configuration parameters dot11MeshHWMProotInterval and dot11MeshHWMPactivePathToRootTimeout to be used by proactive PREQ mechanism. Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com> [line-break commit log] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 13 6月, 2012 2 次提交
-
-
由 Pontus Fuchs 提交于
If you add a monitor interface in parallel to a normal interface mac80211 will let you to change the channel type on the monitor interface even if you are connected. Add an explicit check to disallow this. Signed-off-by: NPontus Fuchs <pontus.fuchs@gmail.com> [fix typo in commit log, use sdata instead of netdev] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
In my redesign of remain-on-channel I forgot that an item could be cancelled when it's a dependent item that is part of another item. Allow cancelling such items by removing them from the dependents list. Note that when we cancel the main item, all its dependents are also cancelled. It would be possible to not do that, but would need tricks to promote an item from dependent to top-level and is tricky in the HW ROC case. Reported-by: NIlan Peer <ilan.peer@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 11 6月, 2012 2 次提交
-
-
由 Johannes Berg 提交于
Ilan pointed out to me that ieee80211_start_next_roc() already calls ieee80211_run_deferred_scan() if the list of ROC items is empty, so there's no need to call it again after calling ieee80211_start_next_roc(). Reported-by: NIlan Peer <ilan.peer@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Chun-Yeow Yeoh 提交于
fix the coding style related to mesh parameters, especially the indentation, as pointed out by Johannes Berg. Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 09 6月, 2012 2 次提交
-
-
由 Javier Cardona 提交于
Signed-off-by: NJavier Cardona <javier@cozybit.com> Reviewed-by: NJason Abele <jason@cozybit.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Javier Cardona 提交于
Signed-off-by: NJavier Cardona <javier@cozybit.com> Reviewed-by: NJason Abele <jason@cozybit.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 07 6月, 2012 8 次提交
-
-
由 Johannes Berg 提交于
Redesign all the off-channel code, getting rid of the generic off-channel work concept, replacing it with a simple remain-on-channel list. This fixes a number of small issues with the ROC implementation: * offloaded remain-on-channel couldn't be queued, now we can queue it as well, if needed * in iwlwifi (the only user) offloaded ROC is mutually exclusive with scanning, use the new queue to handle that case -- I expect that it will later depend on a HW flag The bigger issue though is that there's a bad bug in the current implementation: if we get a mgmt TX request while HW roc is active, and this new request has a wait time, we actually schedule a software ROC instead since we can't guarantee the existing offloaded ROC will still be that long. To fix this, the queuing mechanism was needed. The queuing mechanism for offloaded ROC isn't yet optimal, ideally we should add API to have the HW extend the ROC if needed. We could add that later but for now use a software implementation. Overall, this unifies the behaviour between the offloaded and software-implemented case as much as possible. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
The IDLE handling in HW off-channel is broken right now since we turn off IDLE only when the off-channel period already started. Therefore, all drivers that use it today (only iwlwifi!) must support off-channel while idle, so playing with idle isn't needed at all. Off-channel in general, since it's no longer used for authentication/association, shouldn't affect PS, so also remove that logic. Also document a small caveat for reporting TX status from off-channel frames in HW remain-on-channel. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Arik Nemtsov 提交于
When performing a HW restart for an AP mode interface, add stations back only after the AP is beaconing. This mimics the normal flow of STA addition on AP. Some devices (wlcore) do not support adding stations before beaconing, so this has the added benefit of making recovery work for them. Signed-off-by: NArik Nemtsov <arik@wizery.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Pontus Fuchs 提交于
drv_resume can get called without a prior call to drv_suspend. Consider the following steps: 1. Suspend is started but driver's drv_suspend returns error. 2. Suspend is aborted. local->wowlan flag is left set. 3. Interface is removed. 4. Suspend again. This time open_count is 0 so drv_suspend is not called and local->wowlan not cleared. 5. On resume ieee80211_reconfig will call drv_resume since local->wowlan is set. Signed-off-by: NPontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Chun-Yeow Yeoh 提交于
Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Make mac80211 print a message when it disables HT due to the connection using WEP/TKIP or due to the AP not supporting WMM/QoS. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislaw Gruszka 提交于
For each EDCA TX queue change default settings (in STA mode) to conform old 802.11b/g channel access rules. This is needed for drivers that do not have QoS enable/disable "switch" (like rt2x00) to make them work properly with legacy APs. Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Now that we've removed all uses of the set_channel API except for the monitor channel and in libertas, clarify this. Split the libertas mesh use into a new libertas_set_mesh_channel() operation, just to keep backward compatibility, and rename the normal set_channel() to set_monitor_channel(). Also describe the desired set_monitor_channel() semantics more clearly. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 06 6月, 2012 15 次提交
-
-
由 Johannes Berg 提交于
Just like the AP mode patch, instead of setting the channel and then joining the mesh network, provide the channel to join the network on to the join_mesh() function. Like in AP mode, you can also give the channel to the join-mesh nl80211 command now. Unlike AP mode, it picks a default channel if none was given. As libertas uses mesh mode interfaces but has no join_mesh callback and we can't simply break it, keep some compatibility code for that case and configure the channel directly for it. In the non-libertas case, where we store the channel until join, allow setting it while the interface is down. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Instead of setting the channel first and then starting the AP, let cfg80211 store the channel and provide it as one of the AP settings. This means that now you have to set the channel before you can start an AP interface, but since hostapd/wpa_supplicant always do that we're OK with this change. Alternatively, it's now possible to give the channel as an attribute to the start-ap nl80211 command, overriding any preset channel. Cc: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Change cfg80211_can_beacon_sec_chan() to return true if there is no secondary channel to simplify all the current users of it. They all check the channel type before calling the function because it returns false if there's no secondary channel. Also actually document the return value. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Move the set_channel function up so it can be used by other code in this file in the future. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
There's no need for ieee80211_set_channel to check whether a change in configuration happened since ieee80211_hw_config() auto-detects it. Additionally, it's wrong to pretend the HT config for the BSS changed, it didn't, the BSS can't be up & running (AP beaconing etc.) when the channel type is changed anyway. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Instead of passing around the entire HT information IE, extract only the HT parameters field and disable HT if the HT information IE isn't present and well- formed. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Eliad Peller 提交于
ieee80211_get_operstate() was used by drivers in order to know whether the sta link is up, but it's no longer needed (nor used) as mac80211 notifies the drivers about authorization changes (via the sta_state callback) Signed-off-by: NEliad Peller <eliad@wizery.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Joe Perches 提交于
Simplify the use of #ifdef CONFIG_MAC80211_IBSS_DEBUG/#endif by adding a logging macro to encapsulate the test. Convert the appropriate uses too. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Joe Perches 提交于
Simplify the use of #ifdef CONFIG_MAC80211_HT_DEBUG/#endif by adding a logging macro to encapsulate the test. Convert the appropriate uses too. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Joe Perches 提交于
Standardize the debugging to be able to use dynamic_debug. Coalesce formats, align arguments. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Holger Schurig 提交于
Send beacon loss events to userspace, so it will be able to initiate roaming before disconnection Signed-off-by: NHolger Schurig <holgerschurig@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Thomas Pedersen 提交于
Allow channel change on a mesh interface if the interface is up and no mesh is started. Signed-off-by: NThomas Pedersen <thomas@cozybit.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Eliad Peller 提交于
ieee80211_rx_mgmt_auth() doesn't handle denied authentication properly - it authenticates the station and waits for association (for 5 seconds) instead of failing the authentication. Fix it by destroying auth_data and bailing out instead. Signed-off-by: NEliad Peller <eliad@wizery.com> Acked-by: NJohannes Berg <johannes@sipsolutions.net> Cc: stable@vger.kernel.org #3.4 Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Eliad Peller 提交于
Commit 3a25a8c8 ("mac80211: add improved HW queue control") added support for offchannel queue mapping. However, this mapping is only valid when the driver supports IEEE80211_HW_QUEUE_CONTROL. Check whether the driver supports IEEE80211_HW_QUEUE_CONTROL before setting the hw_queue to the mapped offchannel queue. (This patch doesn't have any actual effect, because hw_queue is overridden in ieee80211_tx() anyway, so this is merely some cleanup) Signed-off-by: NEliad Peller <eliad@wizery.com> Acked-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Arik Nemtsov 提交于
Low level drivers can now set certain netdev feature bits in netdev_features member of the ieee80211_hw struct. These will be propagated to every netdev created from this HW. The white-listed features currently include only ones related to HW checksumming. Signed-off-by: NArik Nemtsov <arik@wizery.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 05 6月, 2012 4 次提交
-
-
由 Arik Nemtsov 提交于
sta_info_cleanup locks the sta_list using rcu_read_lock however the delete operation isn't rcu safe. A race between sta_info_cleanup timer being called and a STA being removed can occur which leads to a panic while traversing sta_list. Fix this by switching to the RCU-safe versions. Cc: stable@vger.kernel.org Reported-by: NEyal Shapira <eyal@wizery.com> Signed-off-by: NArik Nemtsov <arik@wizery.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Joe Perches 提交于
Using | with a constant is always true. Likely this should have be &. cc: Ben Greear <greearb@candelatech.com> Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Fixes a lockdep warning: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- net/mac80211/agg-rx.c:148 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 1 lock held by arecord/11226: #0: (&tid_agg_rx->session_timer){+.-...}, at: [<ffffffff81066bb0>] call_timer_fn+0x0/0x360 stack backtrace: Pid: 11226, comm: arecord Not tainted 3.1.0-kml #16 Call Trace: <IRQ> [<ffffffff81093454>] lockdep_rcu_dereference+0xa4/0xc0 [<ffffffffa02778c9>] sta_rx_agg_session_timer_expired+0xc9/0x110 [mac80211] [<ffffffffa0277800>] ? ieee80211_process_addba_resp+0x220/0x220 [mac80211] [<ffffffff81066c3a>] call_timer_fn+0x8a/0x360 [<ffffffff81066bb0>] ? init_timer_deferrable_key+0x30/0x30 [<ffffffff81477bb0>] ? _raw_spin_unlock_irq+0x30/0x70 [<ffffffff81067049>] run_timer_softirq+0x139/0x310 [<ffffffff81091d5e>] ? put_lock_stats.isra.25+0xe/0x40 [<ffffffff810922ac>] ? lock_release_holdtime.part.26+0xdc/0x160 [<ffffffffa0277800>] ? ieee80211_process_addba_resp+0x220/0x220 [mac80211] [<ffffffff8105cb78>] __do_softirq+0xc8/0x3c0 [<ffffffff8108f088>] ? tick_dev_program_event+0x48/0x110 [<ffffffff8108f16f>] ? tick_program_event+0x1f/0x30 [<ffffffff81153b15>] ? putname+0x35/0x50 [<ffffffff8147a43c>] call_softirq+0x1c/0x30 [<ffffffff81004c55>] do_softirq+0xa5/0xe0 [<ffffffff8105d1ee>] irq_exit+0xae/0xe0 [<ffffffff8147ac6b>] smp_apic_timer_interrupt+0x6b/0x98 [<ffffffff81479ab3>] apic_timer_interrupt+0x73/0x80 <EOI> [<ffffffff8146aac6>] ? free_debug_processing+0x1a1/0x1d5 [<ffffffff81153b15>] ? putname+0x35/0x50 [<ffffffff8146ab2b>] __slab_free+0x31/0x2ca [<ffffffff81477c3a>] ? _raw_spin_unlock_irqrestore+0x4a/0x90 [<ffffffff81253b8f>] ? __debug_check_no_obj_freed+0x15f/0x210 [<ffffffff81097054>] ? lock_release_nested+0x84/0xc0 [<ffffffff8113ec55>] ? kmem_cache_free+0x105/0x250 [<ffffffff81153b15>] ? putname+0x35/0x50 [<ffffffff81153b15>] ? putname+0x35/0x50 [<ffffffff8113ed8f>] kmem_cache_free+0x23f/0x250 [<ffffffff81153b15>] putname+0x35/0x50 [<ffffffff81146d8d>] do_sys_open+0x16d/0x1d0 [<ffffffff81146e10>] sys_open+0x20/0x30 [<ffffffff81478f42>] system_call_fastpath+0x16/0x1b Reported-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
When any interface goes down, it could be the one that we were doing a remain-on-channel with. We therefore need to cancel the remain-on-channel and flush the related work structs so they don't run after the interface has been removed or even destroyed. It's also possible in this case that an off-channel SKB was never transmitted, so free it if this is the case. Note that this can also happen if the driver finishes the off-channel period without ever starting it. Cc: stable@kernel.org Reported-by: NNirav Shah <nirav.j2.shah@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-