- 26 8月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
Jouni reported that with mac80211_hwsim, multicast TX was causing crashes due to invalid vif->cab_queue assignment. It turns out that this is caused by change_interface() getting invoked and not having the vif->type/vif->p2p assigned correctly before calling the queue check (ieee80211_check_queues). Fix this by passing the 'external' interface type to the function and adjusting it accordingly. While at it, also fix the error path in change_interface, it wasn't correctly resetting to the external type but using the internal one instead. Fortunately this affects on hwsim because all other drivers set the vif->type/vif->p2p variables when changing iftype. This shouldn't be needed, but almost all implementations actually do it for their own internal handling. Reported-by: NJouni Malinen <j@w1.fi> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 02 8月, 2013 1 次提交
-
-
由 Simon Wunderlich 提交于
The count field in CSA must be decremented with each beacon transmitted. This patch implements the functionality for drivers using ieee80211_beacon_get(). Other drivers must call back manually after reaching count == 0. This patch also contains the handling and finish worker for the channel switch command, and mac80211/chanctx code to allow to change a channel definition of an active channel context. Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> [small cleanups, catch identical chandef] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 16 7月, 2013 1 次提交
-
-
由 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>
-
- 29 5月, 2013 2 次提交
-
-
由 Felix Fietkau 提交于
Support them only if the driver advertises support for them via IEEE80211_HW_SUPPORTS_ACTIVE_MONITOR. Unlike normal monitor interfaces, they are added to the driver, along with their MAC address. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Jiri Pirko 提交于
So far, only net_device * could be passed along with netdevice notifier event. This patch provides a possibility to pass custom structure able to provide info that event listener needs to know. Signed-off-by: NJiri Pirko <jiri@resnulli.us> v2->v3: fix typo on simeth shortened dev_getter shortened notifier_info struct name v1->v2: fix notifier_call parameter in call_netdevice_notifier() Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 27 5月, 2013 3 次提交
-
-
由 Helmut Schaa 提交于
When changing the MAC address of a single vif mac80211 will check if the new address fits into the address mask specified by the driver. This only needs to be done when using multiple BSSIDs. Hence, check the new address only against all other vifs. Also fix the MAC address assignment on new interfaces if the user changed the address of a vif such that perm_addr is not covered by addr_mask anymore. Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=57371Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NJakub Kicinski <kubakici@wp.pl> Reported-by: NAlessandro Lannocca <alessandro.lannocca@gmail.com> Cc: Alessandro Lannocca <alessandro.lannocca@gmail.com> Cc: Bruno Randolf <br1@thinktube.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Since Eric's commit efe117ab ("Speedup ieee80211_remove_interfaces") there's a bug in mac80211 when it unregisters with AP_VLAN interfaces up. If the AP_VLAN interface was registered after the AP it belongs to (which is the typical case) and then we get into this code path, unregister_netdevice_many() will crash because it isn't prepared to deal with interfaces being closed in the middle of it. Exactly this happens though, because we iterate the list, find the AP master this AP_VLAN belongs to and dev_close() the dependent VLANs. After this, unregister_netdevice_many() won't pick up the fact that the AP_VLAN is already down and will do it again, causing a crash. Cc: stable@vger.kernel.org [2.6.33+] Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
A lot of code in mac80211 assumes that the hw queues are set up correctly for all interfaces (except for monitor) but this isn't true for AP_VLAN interfaces. Fix this by copying the AP master configuration when an AP VLAN is brought up, after this the AP interface can't change its configuration any more and needs to be brought down to change it, which also forces AP_VLAN interfaces down, so just copying in open() is sufficient. Reported-by: NJouni Malinen <j@w1.fi> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 24 5月, 2013 3 次提交
-
-
由 Johannes Berg 提交于
Since Eric's commit efe117ab ("Speedup ieee80211_remove_interfaces") there's a bug in mac80211 when it unregisters with AP_VLAN interfaces up. If the AP_VLAN interface was registered after the AP it belongs to (which is the typical case) and then we get into this code path, unregister_netdevice_many() will crash because it isn't prepared to deal with interfaces being closed in the middle of it. Exactly this happens though, because we iterate the list, find the AP master this AP_VLAN belongs to and dev_close() the dependent VLANs. After this, unregister_netdevice_many() won't pick up the fact that the AP_VLAN is already down and will do it again, causing a crash. Cc: stable@vger.kernel.org [2.6.33+] Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
A lot of code in mac80211 assumes that the hw queues are set up correctly for all interfaces (except for monitor) but this isn't true for AP_VLAN interfaces. Fix this by copying the AP master configuration when an AP VLAN is brought up, after this the AP interface can't change its configuration any more and needs to be brought down to change it, which also forces AP_VLAN interfaces down, so just copying in open() is sufficient. Reported-by: NJouni Malinen <j@w1.fi> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The code I added in "mac80211: don't start new netdev queues if driver stopped" crashes for monitor and AP VLAN interfaces because while they have a netdev, they don't have queues set up by the driver. To fix the crash, exclude these from queue accounting here and just start their netdev queues unconditionally. For monitor, this is the best we can do, as we can redirect frames there to any other interface and don't know which one that will since it can be different for each frame. For AP VLAN interfaces, we can do better later and actually properly track the queue status. Not doing this is really a separate bug though. Reported-by: NIlan Peer <ilan.peer@intel.com> Reported-by: NJouni Malinen <j@w1.fi> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 22 4月, 2013 1 次提交
-
-
由 Bob Copeland 提交于
The RCU docs used to state that rcu_barrier() included a wait for an RCU grace period; however the comments for rcu_barrier() as of commit f0a0e6f2... "rcu: Clarify memory-ordering properties of grace-period primitives" contradict this. So add back synchronize_{rcu,net}() to where they once were, but keep the rcu_barrier()s for the call_rcu() callbacks. Cc: stable <stable@vger.kernel.org> Signed-off-by: NBob Copeland <bob@cozybit.com> Reviewed-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 08 4月, 2013 8 次提交
-
-
由 Johannes Berg 提交于
feng xiangjun reports that my commit 382a103b Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Mar 22 22:30:09 2013 +0100 mac80211: fix idle handling sequence broke the wireless status LED. The reason is that we now call ieee80211_idle_off() when the channel context is assigned, and that doesn't recalculate the LED state. Fix this by making that function a wrapper around most of idle recalculation while forcing active. Reported-by: Nfeng xiangjun <fengxj325@gmail.com> Tested-by: Nfeng xiangjun <fengxj325@gmail.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
If a new netdev (e.g. an AP VLAN) is created while the driver has queues stopped, the new netdev queues will be started even though they shouldn't. This will lead to frames accumulating on the internal mac80211 pending queues instead of properly being held on the netdev queues. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Given the (nested) switch statements, this code can't be reached, so make it warn instead of manipulating the carrier state which seems purposeful. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
When a device is unplugged while suspended, mac80211 is de-initialized and all interfaces are removed while no state is actually present in the driver. This can cause warnings and driver confusion. Fix this by reordering the do_stop code to not call the driver when it is suspended, i.e. when there's no state in the driver anyway. The previous patches removed a few corner cases in ROC and virtual monitor interfaces so that now this is safe to do and no state should be left over. Reported-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
It has to be removed from the driver, but completely destroying it helps handle unplug of a device during suspend since then the channel context handling etc. doesn't have to happen later when it's removed. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
They can't really be executed while suspended and could trigger work warnings, so abort all ROC items. When the system resumes the notifications about this will be delivered to userspace which can then act accordingly (though it will assume they were canceled/finished.) Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The code now explicitly calls ieee80211_configure_filter() anyway, so nothing needs to be explained. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The master interface no longer exists ... and hasn't for a few years now, so remove this reference :-) Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 25 3月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
Corey Richardson reported that my idle handling cleanup (commit fd0f979a, "mac80211: simplify idle handling") broke ath9k_htc. The reason appears to be that it wants to go out of idle before switching channels. To fix it, reimplement that sequence. Reported-by: NCorey Richardson <corey@octayn.net> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 21 3月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
The virtual monitor interface has a locking issue, it calls into the channel context code with the iflist mutex held which isn't allowed since it is usually acquired the other way around. The mutex is still required for the interface iteration, but need not be held across the channel calls. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 19 3月, 2013 2 次提交
-
-
由 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>
-
由 Stanislaw Gruszka 提交于
This basically reverts commit b207cdb0. Now is possible to use drv_{add,remove}_interface() and vif->debugfs_dir to create/remove per interface debugfs files. Remove redundant callbacks. Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 11 3月, 2013 1 次提交
-
-
由 Alexander Bondar 提交于
Some devices have multicast filter capability for each individual virtual interface rather than just a global one. Add an interface specific driver callback allowing such drivers to configure this. Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 06 3月, 2013 4 次提交
-
-
由 Johannes Berg 提交于
For AP interfaces, there's no need to flush stations or keys again when the interface is stopped as already happened when the BSS was stopped on the interface. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Since hostapd will remove keys this isn't usually an issue, but we shouldn't leak keys to the next BSS started on the same interface. For VLANs this also fixes a bug, keys that aren't removed would otherwise be leaked. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
During roaming, the crypto_tx_tailroom_needed_cnt counter will often take values 2,1,0,1,2 because first keys are removed and then new keys are added. This is inefficient because during the 0->1 transition, synchronize_net must be called to avoid packet races, although typically no packets would be flowing during that time. To avoid that, defer the decrement (2->1, 1->0) when keys are removed (by half a second). This means the counter will really have the values 2,2,2,3,4 ... 2, thus never reaching 0 and having to do the 0->1 transition. Note that this patch entirely disregards the drivers for which this optimisation was done to start with, for them the key removal itself will be expensive because it has to synchronize_net() after the counter is incremented to remove the key from HW crypto. For them the sequence will look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a lot more inefficient. This could be addressed separately, during key removal the 0->1->0 sequence isn't necessary. (*) it starts at 0 because HW crypto is on, then goes to 1 when HW crypto is disabled for a key, then back to 0 because the key is deleted; this happens for both keys in the example. When new keys are added, it goes to 1 first because they're added in software; when a key is moved to hardware it goes back to 0 Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Stanislaw Gruszka 提交于
Since two years no mac80211 driver implement support for NAPI. Looks this feature is unneeded, so remove it from generic mac80211 code. Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 03 3月, 2013 1 次提交
-
-
由 Felix Fietkau 提交于
When setting a monitor interface up or down, the idle state needs to be recalculated, otherwise the hardware will just stay in its previous idle state. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 27 2月, 2013 1 次提交
-
-
由 Felix Fietkau 提交于
When the driver does not want a monitor mode VIF, no channel context is allocated for it. This causes ieee80211_recalc_idle to put the hardware into idle mode if only a monitor mode is active, breaking injection. Fix this by checking local->monitors in addition to active channel contexts. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 18 2月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
If an interface is set down while authenticating or associating, there's a station entry that will be removed by the flushing in do_stop() and that will cause a warning. It's otherwise harmless, but avoid the warning by calling ieee80211_mgd_stop() first. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 15 2月, 2013 3 次提交
-
-
由 Bob Copeland 提交于
Since mesh powersaving was added, pending bcast/mcast frames may go out the CAB queue now. Unfortunately, the queue was only set up for AP mode, so we would try to tx on the IEEE80211_INVAL_HW_QUEUE. Allow cab_queue for mesh interfaces as well. Fixes the following warning (or crash without MAC80211_VERBOSE_DEBUG): WARNING: at net/mac80211/tx.c:1223 __ieee80211_tx+0x162/0x35f [mac80211]() Modules linked in: mac80211_hwsim mac80211 cfg80211 [...] Pid: 3085, comm: avahi-daemon Tainted: G W 3.8.0-rc1+ #377 Call Trace: [<ffffffff81045c20>] warn_slowpath_common+0x83/0x9c [<ffffffff81045c53>] warn_slowpath_null+0x1a/0x1c [<ffffffffa083aef0>] __ieee80211_tx+0x162/0x35f [mac80211] [<ffffffffa083cb1d>] ieee80211_tx+0xd3/0xf9 [mac80211] [<ffffffffa083cc0f>] ieee80211_xmit+0xcc/0xd5 [mac80211] [<ffffffffa083db59>] ieee80211_subif_start_xmit+0xc53/0xcd8 [mac80211] [<ffffffff81319acd>] dev_hard_start_xmit+0x259/0x3ce [<ffffffff81333d6b>] sch_direct_xmit+0x74/0x17d [<ffffffff8131a0b1>] dev_queue_xmit+0x230/0x414 [<ffffffff8134877a>] ip_finish_output2+0x348/0x3aa [<ffffffff81349029>] ip_finish_output+0x6c/0x71 [<ffffffff81349046>] NF_HOOK_COND.constprop.44+0x18/0x58 [<ffffffff8134a03a>] ip_mc_output+0x134/0x13c [<ffffffff8134835a>] dst_output+0x18/0x1c [<ffffffff81349a24>] ip_local_out+0x20/0x24 [<ffffffff8134a8cf>] ip_send_skb+0x16/0x3c [<ffffffff8136bfba>] udp_send_skb+0x254/0x2b9 [<ffffffff8136c85e>] udp_sendmsg+0x5a8/0x7d4 Signed-off-by: NBob Copeland <bob@cozybit.com> 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>
-
- 12 2月, 2013 3 次提交
-
-
由 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>
-
由 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>
-
- 19 1月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
Depending on the driver, having ARP filtering for some addresses may be possible. Remove the logic that tracks whether ARP filter is enabled or not and give the driver the total number of addresses instead of the length of the list so it can make its own decision. Reviewed-by: NLuciano Coelho <coelho@ti.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 03 1月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
Instead of checking every time bss_info_changed is called, assign the pointer once depending on the interface type and then leave it untouched until the interface type is changed. This makes the ieee80211_bss_info_change_notify() now a simple wrapper to call the driver only. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-