aboutsummaryrefslogtreecommitdiffstats
path: root/net/wireless
Commit message (Collapse)AuthorAgeFilesLines
* cfg80211: allow registering to beaconsJohannes Berg2016-03-112-1/+71
| | | | | | | | | | Add the ability to register to received beacon frames to allow implementing OLBC logic in userspace. The registration is per wiphy since there's no point in receiving the same frame multiple times. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* nl80211: add API to probe a clientJohannes Berg2016-03-111-0/+104
| | | | | | | | | When the AP SME in hostapd is used it wants to probe the clients when they have been idle for some time. Add explicit API to support this. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* nl80211: allow subscribing to unexpected class3 framesJohannes Berg2016-03-113-0/+85
| | | | | | | | | | | To implement AP mode without monitor interfaces we need to be able to send a deauth to stations that send frames without being associated. Enable this by adding a new nl80211 event for such frames that an application can subscribe to. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* nl80211: advertise device AP SMEJohannes Berg2016-03-112-0/+8
| | | | | | | | | | | | | | | | | | | | Add the ability to advertise that the device contains the AP SME and what features it can support. There are currently no features in the bitmap -- probe response offload will be advertised by a few patches Arik is working on now (who took over from Guy Eilam) and a device with AP SME will typically implement and require response offload. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Conflicts: drivers/net/wireless/ath/ath6kl/init.c Change-Id: Ib1a65814860cf97cadd142c17be0e91f43743832
* nl80211: advertise GTK rekey support, new triggersJohannes Berg2016-03-112-0/+53
| | | | | | | | | | | Since we now have the necessary API in place to support GTK rekeying, applications will need to know whether it is supported by a device. Add a pseudo-trigger that is used only to advertise that capability. Also, add some new triggers that match what iwlagn devices can do. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* nl80211: support sending TDLS commands/framesArik Nemtsov2016-03-111-0/+85
| | | | | | | | | | | | | | | | | | | | | Add support for sending high-level TDLS commands and TDLS frames via NL80211_CMD_TDLS_OPER and NL80211_CMD_TDLS_MGMT, respectively. Add appropriate cfg80211 callbacks for lower level drivers. Add wiphy capability flags for TDLS support and advertise them via nl80211. Signed-off-by: Arik Nemtsov <arik@wizery.com> Cc: Kalyan C Gaddam <chakkal@iit.edu> Signed-off-by: John W. Linville <linville@tuxdriver.com> Conflicts: include/linux/nl80211.h include/net/cfg80211.h net/wireless/nl80211.c Change-Id: I08e4de6e92680aed35b98838aa999d31963b6d50
* cfg80211/nl80211: Add PMKSA caching candidate eventJouni Malinen2016-03-113-0/+61
| | | | | | | | | | | | | | | | When the driver (or most likely firmware) decides which AP to use for roaming based on internal scan result processing, user space needs to be notified of PMKSA caching candidates to allow RSN pre-authentication to be used. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Conflicts: include/linux/nl80211.h Change-Id: I31aa113747b75f5f35658b857fdfe8d9a75e4534
* cfg80211/nl80211: support GTK rekey offloadJohannes Berg2016-03-113-0/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In certain circumstances, like WoWLAN scenarios, devices may implement (partial) GTK rekeying on the device to avoid waking up the host for it. In order to successfully go through GTK rekeying, the KEK, KCK and the replay counter are required. Add API to let the supplicant hand the parameters to the driver which may store it for future GTK rekey operations. Note that, of course, if GTK rekeying is done by the device, the EAP frame must not be passed up to userspace, instead a rekey event needs to be sent to let userspace update its replay counter. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Conflicts: include/linux/nl80211.h net/wireless/nl80211.c Change-Id: Icd3a157742b08c01a3be20d46d4112e5d4b93a58
* Merge remote-tracking branch 'linux-stable/linux-3.0.y' into ↵Ziyan2015-10-255-20/+64
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | p-android-omap-3.0-dev-espresso Conflicts: Makefile arch/arm/include/asm/hardware/cache-l2x0.h arch/arm/kernel/smp.c arch/arm/mach-omap2/board-4430sdp.c arch/arm/mach-omap2/board-omap4panda.c arch/arm/mach-omap2/opp.c arch/ia64/include/asm/futex.h drivers/bluetooth/ath3k.c drivers/bluetooth/btusb.c drivers/firmware/efivars.c drivers/gpu/drm/i915/intel_lvds.c drivers/gpu/drm/radeon/radeon_atombios.c drivers/gpu/drm/radeon/radeon_irq_kms.c drivers/hwmon/fam15h_power.c drivers/mfd/twl6030-irq.c drivers/mmc/core/sdio.c drivers/net/tun.c drivers/net/usb/ipheth.c drivers/net/usb/usbnet.c drivers/usb/core/hub.c drivers/usb/host/xhci-mem.c drivers/usb/host/xhci.h drivers/usb/musb/omap2430.c drivers/usb/serial/ftdi_sio.c drivers/usb/serial/ftdi_sio_ids.h drivers/usb/serial/option.c drivers/usb/serial/qcserial.c drivers/usb/serial/ti_usb_3410_5052.c drivers/usb/serial/ti_usb_3410_5052.h drivers/video/omap2/dss/hdmi.c fs/splice.c include/asm-generic/pgtable.h include/net/sch_generic.h kernel/cgroup.c kernel/futex.c kernel/time/timekeeping.c net/ipv4/route.c net/ipv4/syncookies.c net/ipv4/tcp_ipv4.c net/wireless/util.c security/commoncap.c sound/soc/soc-dapm.c
| * nl80211: fix mgmt tx status and testmode reporting for netnsMichal Kazior2013-08-111-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit a0ec570f4f69c4cb700d743a915096c2c8f56a99 upstream. These two events were sent to the default network namespace. This caused AP mode in a non-default netns to not work correctly. Mgmt tx status was multicasted to a different (default) netns instead of the one the AP was in. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * wireless: regulatory: fix channel disabling race conditionJohannes Berg2013-05-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 990de49f74e772b6db5208457b7aa712a5f4db86 upstream. When a full scan 2.4 and 5 GHz scan is scheduled, but then the 2.4 GHz part of the scan disables a 5.2 GHz channel due to, e.g. receiving country or frequency information, that 5.2 GHz channel might already be in the list of channels to scan next. Then, when the driver checks if it should do a passive scan, that will return false and attempt an active scan. This is not only wrong but can also lead to the iwlwifi device firmware crashing since it checks regulatory as well. Fix this by not setting the channel flags to just disabled but rather OR'ing in the disabled flag. That way, even if the race happens, the channel will be scanned passively which is still (mostly) correct. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * wireless: allow 40 MHz on world roaming channels 12/13Johannes Berg2012-11-261-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 43c771a1963ab461a2f194e3c97fded1d5fe262f upstream. When in world roaming mode, allow 40 MHz to be used on channels 12 and 13 so that an AP that is, e.g., using HT40+ on channel 9 (in the UK) can be used. Reported-by: Eddie Chapman <eddie@ehuk.net> Tested-by: Eddie Chapman <eddie@ehuk.net> Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * wireless: drop invalid mesh address extension framesJohannes Berg2012-11-171-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 7dd111e8ee10cc6816669eabcad3334447673236 upstream. The mesh header can have address extension by a 4th or a 5th and 6th address, but never both. Drop such frames in 802.11 -> 802.3 conversion along with any frames that have the wrong extension. Reviewed-by: Javier Cardona <javier@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * cfg80211: fix antenna gain handlingFelix Fietkau2012-11-171-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit c4a9fafc77a5318f5ed26c509bbcddf03e18c201 upstream. No driver initializes chan->max_antenna_gain to something sensible, and the only place where it is being used right now is inside ath9k. This leads to ath9k potentially using less tx power than it can use, which can decrease performance/range in some rare cases. Rather than going through every single driver, this patch initializes chan->orig_mag in wiphy_register(), ignoring whatever value the driver left in there. If a driver for some reason wishes to limit it independent from regulatory rulesets, it can do so internally. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * cfg80211: fix possible circular lock on reg_regdb_search()Luis R. Rodriguez2012-10-021-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit a85d0d7f3460b1a123b78e7f7e39bf72c37dfb78 upstream. When call_crda() is called we kick off a witch hunt search for the same regulatory domain on our internal regulatory database and that work gets kicked off on a workqueue, this is done while the cfg80211_mutex is held. If that workqueue kicks off it will first lock reg_regdb_search_mutex and later cfg80211_mutex but to ensure two CPUs will not contend against cfg80211_mutex the right thing to do is to have the reg_regdb_search() wait until the cfg80211_mutex is let go. The lockdep report is pasted below. cfg80211: Calling CRDA to update world regulatory domain ====================================================== [ INFO: possible circular locking dependency detected ] 3.3.8 #3 Tainted: G O ------------------------------------------------------- kworker/0:1/235 is trying to acquire lock: (cfg80211_mutex){+.+...}, at: [<816468a4>] set_regdom+0x78c/0x808 [cfg80211] but task is already holding lock: (reg_regdb_search_mutex){+.+...}, at: [<81646828>] set_regdom+0x710/0x808 [cfg80211] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (reg_regdb_search_mutex){+.+...}: [<800a8384>] lock_acquire+0x60/0x88 [<802950a8>] mutex_lock_nested+0x54/0x31c [<81645778>] is_world_regdom+0x9f8/0xc74 [cfg80211] -> #1 (reg_mutex#2){+.+...}: [<800a8384>] lock_acquire+0x60/0x88 [<802950a8>] mutex_lock_nested+0x54/0x31c [<8164539c>] is_world_regdom+0x61c/0xc74 [cfg80211] -> #0 (cfg80211_mutex){+.+...}: [<800a77b8>] __lock_acquire+0x10d4/0x17bc [<800a8384>] lock_acquire+0x60/0x88 [<802950a8>] mutex_lock_nested+0x54/0x31c [<816468a4>] set_regdom+0x78c/0x808 [cfg80211] other info that might help us debug this: Chain exists of: cfg80211_mutex --> reg_mutex#2 --> reg_regdb_search_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(reg_regdb_search_mutex); lock(reg_mutex#2); lock(reg_regdb_search_mutex); lock(cfg80211_mutex); *** DEADLOCK *** 3 locks held by kworker/0:1/235: #0: (events){.+.+..}, at: [<80089a00>] process_one_work+0x230/0x460 #1: (reg_regdb_work){+.+...}, at: [<80089a00>] process_one_work+0x230/0x460 #2: (reg_regdb_search_mutex){+.+...}, at: [<81646828>] set_regdom+0x710/0x808 [cfg80211] stack backtrace: Call Trace: [<80290fd4>] dump_stack+0x8/0x34 [<80291bc4>] print_circular_bug+0x2ac/0x2d8 [<800a77b8>] __lock_acquire+0x10d4/0x17bc [<800a8384>] lock_acquire+0x60/0x88 [<802950a8>] mutex_lock_nested+0x54/0x31c [<816468a4>] set_regdom+0x78c/0x808 [cfg80211] Reported-by: Felix Fietkau <nbd@openwrt.org> Tested-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * cfg80211: fix interface combinations check for ADHOC(IBSS)Liang Li2012-08-151-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | partial of commit 8e8b41f9d8c8e63fc92f899ace8da91a490ac573 upstream. As part of commit 463454b5dbd8 ("cfg80211: fix interface combinations check"), this extra check was introduced: if ((all_iftypes & used_iftypes) != used_iftypes) goto cont; However, most wireless NIC drivers did not advertise ADHOC in wiphy.iface_combinations[i].limits[] and hence we'll get -EBUSY when we bring up a ADHOC wlan with commands similar to: # iwconfig wlan0 mode ad-hoc && ifconfig wlan0 up In commit 8e8b41f9d8c8e ("cfg80211: enforce lack of interface combinations"), the change below fixes the issue: if (total == 1) return 0; But it also introduces other dependencies for stable. For example, a full cherry pick of 8e8b41f9d8c8e would introduce additional regressions unless we also start cherry picking driver specific fixes like the following: 9b4760e ath5k: add possible wiphy interface combinations 1ae2fc2 mac80211_hwsim: advertise interface combinations 20c8e8d ath9k: add possible wiphy interface combinations And the purpose of the 'if (total == 1)' is to cover the specific use case (IBSS, adhoc) that was mentioned above. So we just pick the specific part out from 8e8b41f9d8c8e here. Doing so gives stable kernels a way to fix the change introduced by 463454b5dbd8, without having to make cherry picks specific to various NIC drivers. Signed-off-by: Liang Li <liang.li@windriver.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * cfg80211: process pending events when unregistering net deviceDaniel Drake2012-08-153-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 1f6fc43e621167492ed4b7f3b4269c584c3d6ccc upstream. libertas currently calls cfg80211_disconnected() when it is being brought down. This causes an event to be allocated, but since the wdev is already removed from the rdev by the time that the event processing work executes, the event is never processed or freed. http://article.gmane.org/gmane.linux.kernel.wireless.general/95666 Fix this leak, and other possible situations, by processing the event queue when a device is being unregistered. Thanks to Johannes Berg for the suggestion. Signed-off-by: Daniel Drake <dsd@laptop.org> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * cfg80211: check iface combinations only when iface is runningMichal Kazior2012-07-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit f8cdddb8d61d16a156229f0910f7ecfc7a82c003 upstream. Don't validate interface combinations on a stopped interface. Otherwise we might end up being able to create a new interface with a certain type, but won't be able to change an existing interface into that type. This also skips some other functions when interface is stopped and changing interface type. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> [Fixes regression introduced by cherry pick of 463454b5dbd8] Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
| * cfg80211: fix potential deadlock in regulatoryEliad Peller2012-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit fe20b39ec32e975f1054c0b7866c873a954adf05 upstream. reg_timeout_work() calls restore_regulatory_settings() which takes cfg80211_mutex. reg_set_request_processed() already holds cfg80211_mutex before calling cancel_delayed_work_sync(reg_timeout), so it might deadlock. Call the async cancel_delayed_work instead, in order to avoid the potential deadlock. This is the relevant lockdep warning: cfg80211: Calling CRDA for country: XX ====================================================== [ INFO: possible circular locking dependency detected ] 3.4.0-rc5-wl+ #26 Not tainted ------------------------------------------------------- kworker/0:2/1391 is trying to acquire lock: (cfg80211_mutex){+.+.+.}, at: [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211] but task is already holding lock: ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 ((reg_timeout).work){+.+...}: [<c008fd44>] validate_chain+0xb94/0x10f0 [<c0090b68>] __lock_acquire+0x8c8/0x9b0 [<c0090d40>] lock_acquire+0xf0/0x114 [<c005b600>] wait_on_work+0x4c/0x154 [<c005c000>] __cancel_work_timer+0xd4/0x11c [<c005c064>] cancel_delayed_work_sync+0x1c/0x20 [<bf28b274>] reg_set_request_processed+0x50/0x78 [cfg80211] [<bf28bd84>] set_regdom+0x550/0x600 [cfg80211] [<bf294cd8>] nl80211_set_reg+0x218/0x258 [cfg80211] [<c03c7738>] genl_rcv_msg+0x1a8/0x1e8 [<c03c6a00>] netlink_rcv_skb+0x5c/0xc0 [<c03c7584>] genl_rcv+0x28/0x34 [<c03c6720>] netlink_unicast+0x15c/0x228 [<c03c6c7c>] netlink_sendmsg+0x218/0x298 [<c03933c8>] sock_sendmsg+0xa4/0xc0 [<c039406c>] __sys_sendmsg+0x1e4/0x268 [<c0394228>] sys_sendmsg+0x4c/0x70 [<c0013840>] ret_fast_syscall+0x0/0x3c -> #1 (reg_mutex){+.+.+.}: [<c008fd44>] validate_chain+0xb94/0x10f0 [<c0090b68>] __lock_acquire+0x8c8/0x9b0 [<c0090d40>] lock_acquire+0xf0/0x114 [<c04734dc>] mutex_lock_nested+0x48/0x320 [<bf28b2cc>] reg_todo+0x30/0x538 [cfg80211] [<c0059f44>] process_one_work+0x2a0/0x480 [<c005a4b4>] worker_thread+0x1bc/0x2bc [<c0061148>] kthread+0x98/0xa4 [<c0014af4>] kernel_thread_exit+0x0/0x8 -> #0 (cfg80211_mutex){+.+.+.}: [<c008ed58>] print_circular_bug+0x68/0x2cc [<c008fb28>] validate_chain+0x978/0x10f0 [<c0090b68>] __lock_acquire+0x8c8/0x9b0 [<c0090d40>] lock_acquire+0xf0/0x114 [<c04734dc>] mutex_lock_nested+0x48/0x320 [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211] [<bf28b200>] reg_timeout_work+0x1c/0x20 [cfg80211] [<c0059f44>] process_one_work+0x2a0/0x480 [<c005a4b4>] worker_thread+0x1bc/0x2bc [<c0061148>] kthread+0x98/0xa4 [<c0014af4>] kernel_thread_exit+0x0/0x8 other info that might help us debug this: Chain exists of: cfg80211_mutex --> reg_mutex --> (reg_timeout).work Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((reg_timeout).work); lock(reg_mutex); lock((reg_timeout).work); lock(cfg80211_mutex); *** DEADLOCK *** 2 locks held by kworker/0:2/1391: #0: (events){.+.+.+}, at: [<c0059e94>] process_one_work+0x1f0/0x480 #1: ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480 stack backtrace: [<c001b928>] (unwind_backtrace+0x0/0x12c) from [<c0471d3c>] (dump_stack+0x20/0x24) [<c0471d3c>] (dump_stack+0x20/0x24) from [<c008ef70>] (print_circular_bug+0x280/0x2cc) [<c008ef70>] (print_circular_bug+0x280/0x2cc) from [<c008fb28>] (validate_chain+0x978/0x10f0) [<c008fb28>] (validate_chain+0x978/0x10f0) from [<c0090b68>] (__lock_acquire+0x8c8/0x9b0) [<c0090b68>] (__lock_acquire+0x8c8/0x9b0) from [<c0090d40>] (lock_acquire+0xf0/0x114) [<c0090d40>] (lock_acquire+0xf0/0x114) from [<c04734dc>] (mutex_lock_nested+0x48/0x320) [<c04734dc>] (mutex_lock_nested+0x48/0x320) from [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [<c0059f44>] (process_one_work+0x2a0/0x480) [<c0059f44>] (process_one_work+0x2a0/0x480) from [<c005a4b4>] (worker_thread+0x1bc/0x2bc) [<c005a4b4>] (worker_thread+0x1bc/0x2bc) from [<c0061148>] (kthread+0x98/0xa4) [<c0061148>] (kthread+0x98/0xa4) from [<c0014af4>] (kernel_thread_exit+0x0/0x8) cfg80211: Calling CRDA to update world regulatory domain cfg80211: World regulatory domain updated: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * cfg80211: fix interface combinations checkJohannes Berg2012-06-171-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 463454b5dbd8dbab6e2fc6c557329e5b811b9c32 upstream. If a given interface combination doesn't contain a required interface type then we missed checking that and erroneously allowed it even though iface type wasn't there at all. Add a check that makes sure that all interface types are accounted for. Reported-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * cfg80211: warn if db.txt is empty with CONFIG_CFG80211_INTERNAL_REGDBLuis R. Rodriguez2012-06-011-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 80007efeff0568375b08faf93c7aad65602cb97e upstream. It has happened twice now where elaborate troubleshooting has undergone on systems where CONFIG_CFG80211_INTERNAL_REGDB [0] has been set but yet net/wireless/db.txt was not updated. Despite the documentation on this it seems system integrators could use some more help with this, so throw out a kernel warning at boot time when their database is empty. This does mean that the error-prone system integrator won't likely realize the issue until they boot the machine but -- it does not seem to make sense to enable a build bug breaking random build testing. [0] http://wireless.kernel.org/en/developers/Regulatory/CRDA#CONFIG_CFG80211_INTERNAL_REGDB Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Youngsin Lee <youngsin@qualcomm.com> Cc: Raja Mani <rmani@qca.qualcomm.com> Cc: Senthil Kumar Balasubramanian <senthilb@qca.qualcomm.com> Cc: Vipin Mehta <vipimeht@qca.qualcomm.com> Cc: yahuan@qca.qualcomm.com Cc: jjan@qca.qualcomm.com Cc: vthiagar@qca.qualcomm.com Cc: henrykim@qualcomm.com Cc: jouni@qca.qualcomm.com Cc: athiruve@qca.qualcomm.com Cc: cjkim@qualcomm.com Cc: philipk@qca.qualcomm.com Cc: sunnykim@qualcomm.com Cc: sskwak@qualcomm.com Cc: kkim@qualcomm.com Cc: mattbyun@qualcomm.com Cc: ryanlee@qualcomm.com Cc: simbap@qualcomm.com Cc: krislee@qualcomm.com Cc: conner@qualcomm.com Cc: hojinkim@qualcomm.com Cc: honglee@qualcomm.com Cc: johnwkim@qualcomm.com Cc: jinyong@qca.qualcomm.com Signed-off-by: Luis R. Rodriguez <mcgrof@frijolero.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * nl80211: ensure interface is up in various APIsJohannes Berg2012-05-071-12/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 2b5f8b0b44e17e625cfba1e7b88db44f4dcc0441 upstream. [backported by Ben Greear] The nl80211 handling code should ensure as much as it can that the interface is in a valid state, it can certainly ensure the interface is running. Not doing so can cause calls through mac80211 into the driver that result in warnings and unspecified behaviour in the driver. Reported-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * cfg80211: fix interface combinations check.Lukasz Kucharczyk2012-04-271-1/+1
| | | | | | | | | | | | | | | | | | commit e55a4046dab28c440c96890bdddcf02dc8981f2d upstream. Signed-off-by: Lukasz Kucharczyk <lukasz.kucharczyk@tieto.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | Merge latest changes from google kernel/common.gitRoman Shaposhnikov2012-06-132-17/+91
| | | | | | | | | | | | | | Kernel version updated to 3.0.31 Change-Id: Ifbd7150801f3beeec9cbaa566f249d8019ef9348 Signed-off-by: Roman Shaposhnikov <x0166637@ti.com>
* | Merge branch 'android-omap-3.0' into p-android-omap-3.0Dan Murphy2012-02-162-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: arch/arm/mach-omap2/Kconfig arch/arm/mach-omap2/clock44xx_data.c arch/arm/mach-omap2/omap_twl.c drivers/gpu/pvr/ion.c drivers/gpu/pvr/ion.h drivers/gpu/pvr/mm.c drivers/gpu/pvr/omap4/syslocal.h drivers/gpu/pvr/sgxfeaturedefs.h drivers/mmc/host/omap_hsmmc.c drivers/usb/gadget/android.c drivers/video/hdmi_ti_4xxx_ip.c drivers/video/omap2/dss/dispc.c drivers/video/omap2/dss/hdmi.c fs/proc/base.c include/video/hdmi_ti_4xxx_ip.h sound/soc/codecs/twl6040.c sound/soc/omap/sdp4430.c Change-Id: Ia1edb1885eff7554aead12780898502df08b7c83 Signed-off-by: Dan Murphy <dmurphy@ti.com>
* | Merge branch 'linux-3.0.18' into p-android-omap-3.0Dan Murphy2012-02-022-18/+37
|\ \ | |/ | | | | | | | | | | | | | | | | | | Conflicts: arch/arm/mach-omap2/smartreflex.c drivers/i2c/busses/i2c-omap.c drivers/usb/host/ehci.h drivers/usb/musb/musb_core.c fs/proc/base.c Signed-off-by: Dan Murphy <dmurphy@ti.com>
| * cfg80211: amend regulatory NULL dereference fixLuis R. Rodriguez2011-12-091-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 0bac71af6e66dc798bf07d0c0dd14ee5503362f9 upstream. Johannes' patch for "cfg80211: fix regulatory NULL dereference" broke user regulaotry hints and it did not address the fact that last_request was left populated even if the previous regulatory hint was stale due to the wiphy disappearing. Fix user reguluatory hints by only bailing out if for those regulatory hints where a request_wiphy is expected. The stale last_request considerations are addressed through the previous fixes on last_request where we reset the last_request to a static world regdom request upon reset_regdomains(). In this case though we further enhance the effect by simply restoring reguluatory settings completely. Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * cfg80211: fix race on init and driver registrationLuis R. Rodriguez2011-12-091-16/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit a042994dd377d86bff9446ee76151ceb6267c9ba upstream. There is a theoretical race that if hit will trigger a crash. The race is between when we issue the first regulatory hint, regulatory_hint_core(), gets processed by the workqueue and between when the first device gets registered to the wireless core. This is not easy to reproduce but it was easy to do so through the regulatory simulator I have been working on. This is a port of the fix I implemented there [1]. [1] https://github.com/mcgrof/regsim/commit/a246ccf81f059cb662eee288aa13100f631e4cc8 Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * cfg80211: fix regulatory NULL dereferenceJohannes Berg2011-12-091-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit de3584bd62d87b4c250129fbc46ca52c80330add upstream. By the time userspace returns with a response to the regulatory domain request, the wiphy causing the request might have gone away. If this is so, reject the update but mark the request as having been processed anyway. Cc: Luis R. Rodriguez <lrodriguez@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * nl80211: fix MAC address validationEliad Peller2011-12-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | commit e007b857e88097c96c45620bf3b04a4e309053d1 upstream. MAC addresses have a fixed length. The current policy allows passing < ETH_ALEN bytes, which might result in reading beyond the buffer. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * cfg80211: fix bug on regulatory core exit on access to last_requestLuis R. Rodriguez2011-11-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 58ebacc66bd11be2327edcefc79de94bd6f5bb4a upstream. Commit 4d9d88d1 by Scott James Remnant <keybuk@google.com> added the .uevent() callback for the regulatory device used during the platform device registration. The change was done to account for queuing up udev change requests through udevadm triggers. The change also meant that upon regulatory core exit we will now send a uevent() but the uevent() callback, reg_device_uevent(), also accessed last_request. Right before commiting device suicide we free'd last_request but never set it to NULL so platform_device_unregister() would lead to bogus kernel paging request. Fix this and also simply supress uevents right before we commit suicide as they are pointless. This fix is required for kernels >= v2.6.39 $ git describe --contains 4d9d88d1 v2.6.39-rc1~468^2~25^2^2~21 The impact of not having this present is that a bogus paging access may occur (only read) upon cfg80211 unload time. You may also get this BUG complaint below. Although Johannes could not reproduce the issue this fix is theoretically correct. mac80211_hwsim: unregister radios mac80211_hwsim: closing netlink BUG: unable to handle kernel paging request at ffff88001a06b5ab IP: [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211] PGD 1836063 PUD 183a063 PMD 1ffcb067 PTE 1a06b160 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU 0 Modules linked in: cfg80211(-) [last unloaded: mac80211] Pid: 2279, comm: rmmod Tainted: G W 3.1.0-wl+ #663 Bochs Bochs RIP: 0010:[<ffffffffa030df9a>] [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211] RSP: 0000:ffff88001c5f9d58 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88001d2eda88 RCX: ffff88001c7468fc RDX: ffff88001a06b5a0 RSI: ffff88001c7467b0 RDI: ffff88001c7467b0 RBP: ffff88001c5f9d58 R08: 000000000000ffff R09: 000000000000ffff R10: 0000000000000000 R11: 0000000000000001 R12: ffff88001c7467b0 R13: ffff88001d2eda78 R14: ffffffff8164a840 R15: 0000000000000001 FS: 00007f8a91d8a6e0(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffff88001a06b5ab CR3: 000000001c62e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process rmmod (pid: 2279, threadinfo ffff88001c5f8000, task ffff88000023c780) Stack: ffff88001c5f9d98 ffffffff812ff7e5 ffffffff8176ab3d ffff88001c7468c2 000000000000ffff ffff88001d2eda88 ffff88001c7467b0 ffff880000114820 ffff88001c5f9e38 ffffffff81241dc7 ffff88001c5f9db8 ffffffff81040189 Call Trace: [<ffffffff812ff7e5>] dev_uevent+0xc5/0x170 [<ffffffff81241dc7>] kobject_uevent_env+0x1f7/0x490 [<ffffffff81040189>] ? sub_preempt_count+0x29/0x60 [<ffffffff814cab1a>] ? _raw_spin_unlock_irqrestore+0x4a/0x90 [<ffffffff81305307>] ? devres_release_all+0x27/0x60 [<ffffffff8124206b>] kobject_uevent+0xb/0x10 [<ffffffff812fee27>] device_del+0x157/0x1b0 [<ffffffff8130377d>] platform_device_del+0x1d/0x90 [<ffffffff81303b76>] platform_device_unregister+0x16/0x30 [<ffffffffa030fffd>] regulatory_exit+0x5d/0x180 [cfg80211] [<ffffffffa032bec3>] cfg80211_exit+0x2b/0x45 [cfg80211] [<ffffffff8109a84c>] sys_delete_module+0x16c/0x220 [<ffffffff8108a23e>] ? trace_hardirqs_on_caller+0x7e/0x120 [<ffffffff814cba02>] system_call_fastpath+0x16/0x1b Code: <all your base are belong to me> RIP [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211] RSP <ffff88001c5f9d58> CR2: ffff88001a06b5ab ---[ end trace 147c5099a411e8c0 ]--- Reported-by: Johannes Berg <johannes@sipsolutions.net> Cc: Scott James Remnant <keybuk@google.com> Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * nl80211: fix HT capability attribute validationJohannes Berg2011-11-261-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 6c7394197af90f6a332180e33f5d025d3037d883 upstream. Since the NL80211_ATTR_HT_CAPABILITY attribute is used as a struct, it needs a minimum, not maximum length. Enforce that properly. Not doing so could potentially lead to reading after the buffer. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* | net: wireless: Skip connect warning for CONFIG_CFG80211_ALLOW_RECONNECTDmitry Shmidt2011-10-281-1/+3
| | | | | | | | Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
* | Merge commit 'v3.0.8' into android-3.0Colin Cross2011-10-272-1/+5
|\ \ | |/
| * cfg80211: Fix validation of AKM suitesJouni Malinen2011-10-031-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 1b9ca0272ffae212e726380f66777b30a56ed7a5 upstream. Incorrect variable was used in validating the akm_suites array from NL80211_ATTR_AKM_SUITES. In addition, there was no explicit validation of the array length (we only have room for NL80211_MAX_NR_AKM_SUITES). This can result in a buffer write overflow for stack variables with arbitrary data from user space. The nl80211 commands using the affected functionality require GENL_ADMIN_PERM, so this is only exposed to admin users. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * wireless: Reset beacon_found while updating regulatoryRajkumar Manoharan2011-10-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit aa3d7eef398dd4f29045e9889b817d5161afe03e upstream. During the association, the regulatory is updated by country IE that reaps the previously found beacons. The impact is that after a STA disconnects *or* when for any reason a regulatory domain change happens the beacon hint flag is not cleared therefore preventing future beacon hints to be learned. This is important as a regulatory domain change or a restore of regulatory settings would set back the passive scan and no-ibss flags on the channel. This is the right place to do this given that it covers any regulatory domain change. Reviewed-by: Luis R. Rodriguez <mcgrof@gmail.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* | net: wireless: Fix CFG80211_ALLOW_RECONNECT option for disconnectDmitry Shmidt2011-10-181-0/+2
| | | | | | | | Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
* | net: wireless: Add CFG80211_ALLOW_RECONNECT optionDmitry Shmidt2011-09-152-0/+13
| | | | | | | | Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
* | net: wireless: change the expire time about each entry of scan resultsjun.ho.lee2011-09-091-1/+1
|/ | | | | | Change-Id: I6e8d838d91bebc28f4cd09dcb8b9f1de775be13d Signed-off-by: jun.ho.lee <jun.ho.lee@samsung.com> Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
* cfg80211: really ignore the regulatory requestSven Neumann2011-08-041-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | commit a203c2aa4cefccb879c879b8e1cad1a09a679e55 upstream. At the beginning of wiphy_update_regulatory() a check is performed whether the request is to be ignored. Then the request is sent to the driver nevertheless. This happens even if last_request points to NULL, leading to a crash in the driver: [<bf01d864>] (lbs_set_11d_domain_info+0x28/0x1e4 [libertas]) from [<c03b714c>] (wiphy_update_regulatory+0x4d0/0x4f4) [<c03b714c>] (wiphy_update_regulatory+0x4d0/0x4f4) from [<c03b4008>] (wiphy_register+0x354/0x420) [<c03b4008>] (wiphy_register+0x354/0x420) from [<bf01b17c>] (lbs_cfg_register+0x80/0x164 [libertas]) [<bf01b17c>] (lbs_cfg_register+0x80/0x164 [libertas]) from [<bf020e64>] (lbs_start_card+0x20/0x88 [libertas]) [<bf020e64>] (lbs_start_card+0x20/0x88 [libertas]) from [<bf02cbd8>] (if_sdio_probe+0x898/0x9c0 [libertas_sdio]) Fix this by returning early. Also remove the out: label as it is not any longer needed. Signed-off-by: Sven Neumann <s.neumann@raumfeld.com> Cc: linux-wireless@vger.kernel.org Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Daniel Mack <daniel@zonque.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* cfg80211: fix deadlock with rfkill/sched_scan by adding new mutexLuciano Coelho2011-07-054-14/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | There was a deadlock when rfkill-blocking a wireless interface, because we were locking the rdev mutex on NETDEV_GOING_DOWN to stop sched_scans that were eventually running. The rfkill block code was already holding a mutex under rdev: kernel: ======================================================= kernel: [ INFO: possible circular locking dependency detected ] kernel: 3.0.0-rc1-00049-g1fa7b6a #57 kernel: ------------------------------------------------------- kernel: kworker/0:1/4525 is trying to acquire lock: kernel: (&rdev->mtx){+.+.+.}, at: [<ffffffff8164c831>] cfg80211_netdev_notifier_call+0x131/0x5b0 kernel: kernel: but task is already holding lock: kernel: (&rdev->devlist_mtx){+.+.+.}, at: [<ffffffff8164dcef>] cfg80211_rfkill_set_block+0x4f/0xa0 kernel: kernel: which lock already depends on the new lock. To fix this, add a new mutex specifically for sched_scan, to protect the sched_scan_req element in the rdev struct, instead of using the global rdev mutex. Reported-by: Duane Griffin <duaneg@dghda.com> Signed-off-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: fix rx->key NULL dereference during mic failureArik Nemtsov2011-06-271-1/+2
| | | | | | | | | | | | | | Sometimes when reporting a MIC failure rx->key may be unset. This code path is hit when receiving a packet meant for a multicast address, and decryption is performed in HW. Fortunately, the failing key_idx is not used for anything up to (and including) usermode, so we allow ourselves to drop it on the way up when a key cannot be retrieved. Signed-off-by: Arik Nemtsov <arik@wizery.com> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
* nl80211: fix overflow in ssid_lenLuciano Coelho2011-06-071-5/+4
| | | | | | | | | | | | | | | | | | When one of the SSID's length passed in a scan or sched_scan request is larger than 255, there will be an overflow in the u8 that is used to store the length before checking. This causes the check to fail and we overrun the buffer when copying the SSID. Fix this by checking the nl80211 attribute length before copying it to the struct. This is a follow up for the previous commit 208c72f4fe44fe09577e7975ba0e7fa0278f3d03, which didn't fix the problem entirely. Reported-by: Ido Yariv <ido@wizery.com> Signed-off-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* cfg80211: don't drop p2p probe responsesEliad Peller2011-06-011-19/+24
| | | | | | | | | | | | | | | Commit 0a35d36 ("cfg80211: Use capability info to detect mesh beacons") assumed that probe response with both ESS and IBSS bits cleared means that the frame was sent by a mesh sta. However, these capabilities are also being used in the p2p_find phase, and the mesh-validation broke it. Rename the WLAN_CAPABILITY_IS_MBSS macro, and verify that mesh ies exist before assuming this frame was sent by a mesh sta. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Merge ↵John W. Linville2011-05-271-2/+2
|\ | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem
| * nl80211: fix check for valid SSID size in scan operationsLuciano Coelho2011-05-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In both trigger_scan and sched_scan operations, we were checking for the SSID length before assigning the value correctly. Since the memory was just kzalloc'ed, the check was always failing and SSID with over 32 characters were allowed to go through. This was causing a buffer overflow when copying the actual SSID to the proper place. This bug has been there since 2.6.29-rc4. Cc: stable@kernel.org Signed-off-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | Merge ↵John W. Linville2011-05-244-15/+23
|\ \ | |/ | | | | ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem
| * nl80211: remove some stack variables in trigger_scan and start_sched_scanLuciano Coelho2011-05-191-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Some stack variables (name *ssid and *channel) are only used to define the size of the memory block that needs to be allocated for the request structure in the nl80211_trigger_scan() and nl80211_start_sched_scan() functions. This is unnecessary because the sizes of the actual elements in the structure can be used instead. Signed-off-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * cfg80211: Use consistent BSS matching between scan and smeJouni Malinen2011-05-193-7/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cfg80211 scan code adds separate BSS entries if the same BSS shows up on multiple channels. However, sme implementation does not use the frequency when fetching the BSS entry. Fix this by adding channel information to cfg80211_roamed() and include it in cfg80211_get_bss() calls. Please note that drivers using cfg80211_roamed() need to be modified to fully implement this fix. This commit includes only minimal changes to avoid compilation issues; it maintains the old (broken) behavior for most drivers. ath6kl was the only one that I could test, so I updated it to provide the operating frequency in the roamed event. Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | Merge branch 'master' of ↵John W. Linville2011-05-1610-63/+953
|\ \ | |/ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem Conflicts: drivers/net/wireless/iwlwifi/iwl-agn-tx.c net/mac80211/sta_info.h
generated by cgit v1.1 at 2024-09-07 11:46:31 +0000