summaryrefslogtreecommitdiff
path: root/net
AgeCommit message (Collapse)AuthorFilesLines
2012-03-05mac80211: Fix the generation of PREQs in proactive RANN mechanism of HWMPChun-Yeow Yeoh2-5/+19
According to Section Y.7.4 Actions on receipt of proactive RANN, an individually addressed PREQ should be generated towards the neighbor peer mesh STA indicated in the RANN Sender Address field in the forwarding information. Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-29Merge branch 'master' of ↵John W. Linville2-1/+4
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
2012-02-29mac80211: handle non-bufferable MMPDUs correctlyJohannes Berg2-8/+13
This renames the IEEE80211_TX_CTL_POLL_RESPONSE TX flag to IEEE80211_TX_CTL_NO_PS_BUFFER and also uses it for non-bufferable MMPDUs (all MMPDUs but deauth, disassoc and action frames.) Previously, mac80211 would let the MMPDU through but not set the flag so drivers supporting some hardware aids for avoiding the PS races would then reject the frame. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-29mac80211: make deauth/disassoc sequence more naturalJohannes Berg1-37/+47
The association sequence looks (roughly) like this now: * set BSSID * set station to EXIST state * send auth * set station to AUTH state * send assoc * set station to ASSOC state * set BSS info to associated In contrast, the deauth/disassoc sequence is the other way around: * clear BSSID/BSS info state * remove station * send deauth/disassoc (in some cases the last two steps are reversed.) This patch encodes the entire sequence in the ieee80211_set_disassoc() function and changes it to be like this, for good measure with an explicit flush: * send deauth/disassoc * flush * remove station * clear BSSID/BSS info state At least iwlwifi gets confused with the other sequence in P2P mode and complains that it wasn't able to flush the queues. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-29mac80211: fix ieee80211_set_disassoc() sending DelBAJohannes Berg1-3/+3
When ieee80211_set_disassoc() is called with the tx argument set to true, it will send DelBA out to the peer. This isn't useful or necessary in a few cases where we do it today, those being when we lost the connection or when the supplicant explicitly asked us to not tell the AP. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-29mac80211: dont call cfg80211 from ieee80211_send_deauth_disassocJohannes Berg1-33/+38
Instead of calling cfg80211 in ieee80211_send_deauth_disassoc() pass out the frame and call it from the caller. That saves the SKB allocation if we don't actually want to send the frame and enables us to make the ordering smarter in the future. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-29cfg80211: remove cookies from callbacksJohannes Berg4-29/+23
In "cfg80211: no cookies in cfg80211_send_XXX()" Holger Schurig removed the cookies in the calls from mac80211 to cfg80211, but the ones in the other direction were left in. Remove them now. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-27mac80211: remove local_to_hwJohannes Berg4-11/+5
That's a lot longer than open-coding it and doesn't really add value, so just remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-27mac80211: fix sta_info_flush() return valueJohannes Berg1-1/+3
The comment for sta_info_flush() states "Returns the number of removed STA entries" but that isn't actually true. Consequently, the warning when a station is still around on interface removal can never trigger and this delayed finding the timer issue the previous patch fixed. Fix the return value here to make that warning useful again. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-27mac80211: fix auth/assoc data & timer leakJohannes Berg3-0/+16
When removing an interface while it is in the process of authenticating or associating, we leak the auth_data or assoc_data, and leave the timer pending. The timer then crashes the system when it fires as its data is gone. Fix this by explicitly deleting all the data when the interface is removed. This uncovered another bug -- this problem should have been detected by the sta_info_flush() warning but that function doesn't ever return non-zero, I'll fix that in a separate patch. Reported-by: Hieu Nguyen <hieux.c.nguyen@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-27mac80211: use proper sub_if_data on suspend pathJakub Kicinski1-1/+1
Use interface data from sta instead of invalid pointer to list head in calls to drv_sta_state. Signed-off-by: Jakub Kicinski <kubakici@wp.pl> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-27mac80211: fix associated vs. idle raceJohannes Berg1-1/+15
Eliad reports that if a scan finishes in the middle of processing associated (however it happens), the interface can go idle. This is because we set assoc_data to NULL before we set associated. Change the order so any idle check will find either one of them. Doing this requires duplicating the TX sync processing, but I already have a patch to delete that completely and will submit that as soon as my driver changes to no longer require it are submitted. Reported-by: Eliad Peller <eliad@wizery.com> Tested-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-27mac80211: clean up asm/unaligned.h inclusionJohannes Berg6-2/+4
Some files implicitly get this via mesh.h which itself doesn't need it, so move the inclusion into the right files. Some other files don't need it at all but include it, so remove it from there. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-27mac80211: remove redundant monitor_work enqueueingEliad Peller1-1/+0
ieee80211_restart_sta_timer() takes care for enqueueing monitor_work if needed, so no need to do it again. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-27mac80211: don't queue monitor work for HW_CONNECTION_MONITOREliad Peller1-2/+6
Devices that monitor the connection in the hw don't need the monitor work in the driver. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-22cfg80211: restructure AP/GO mode APIJohannes Berg4-206/+210
The AP/GO mode API isn't very clearly defined, it has "set beacon" and "new beacon" etc. Modify the API to the following: * start AP -- all settings * change beacon -- new beacon data * stop AP -- stop AP mode operation This also reflects in the nl80211 API, rename the commands there correspondingly (but keep the old names for compatibility.) Overall, this makes it much clearer what's going on in the API. Kalle developed the ath6kl changes, I created the rest of the patch. Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-21mac80211: Fix a warning on changing to monitor mode from STAMohammed Shafi Shajakhan1-0/+3
nothing needs to be done for monitor/AP_VLAN mode on calling ieee80211_bss_info_change_notify -> drv_bss_info_changed with the change flag 'BSS_CHANGED_IDLE'. 'wl1271' seems to use BSS_CHANGED_IDLE only for STA and IBSS mode. further the non-idle state of the monitor mode is taken care by the 'count' variable which counts non-idle interfaces. ieee80211_idle_off(local, "in use") will be called. this fixes the following WARNING when we have initially STA mode (network manager running) and not associated, and change it to monitor mode with network manager disabled and bringing up the monitor mode. this changes the idle state from 'true' (STA unassociated) to 'false' (MONITOR mode) exposed by the commit 405385f8ce7a2ed8f82e216d88b5282142e1288b "mac80211: set bss_conf.idle when vif is connected" WARNING: net/mac80211/main.c:212 ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]() Hardware name: 64756D6 Pid: 3835, comm: ifconfig Tainted: G O 3.3.0-rc3-wl #9 Call Trace: [<c0133b02>] warn_slowpath_common+0x72/0xa0 [<fc8e8c3f>] ? ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211] [<fc8e8c3f>] ? ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211] [<c0133b52>] warn_slowpath_null+0x22/0x30 [<fc8e8c3f>] ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211] [<fc8f9de3>] __ieee80211_recalc_idle+0x113/0x430 [mac80211] [<fc8fabc6>] ieee80211_do_open+0x156/0x7e0 [mac80211] [<fc8f8a25>] ? ieee80211_check_concurrent_iface+0x25/0x180 [mac80211] [<c015dd9f>] ? raw_notifier_call_chain+0x1f/0x30 [<fc8fb290>] ieee80211_open+0x40/0x80 [mac80211] [<c05894f6>] __dev_open+0x96/0xe0 [<c068fba5>] ? _raw_spin_unlock_bh+0x35/0x40 [<c05881d9>] __dev_change_flags+0x109/0x170 [<c0589423>] dev_change_flags+0x23/0x60 [<c05f3770>] devinet_ioctl+0x6a0/0x770 ieee80211 phy0: device no longer idle - in use Cc: Eliad Peller <eliad@wizery.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-21mac80211: zero initialize count field in ieee80211_tx_rateMohammed Shafi Shajakhan1-1/+1
rate control algorithms concludes the rate as invalid with rate[i].idx < -1 , while they do also check for rate[i].count is non-zero. it would be safer to zero initialize the 'count' field. recently we had a ath9k rate control crash where the ath9k rate control in ath_tx_status assumed to check only for rate[i].count being non-zero in one instance and ended up in using invalid rate index for 'connection monitoring NULL func frames' which eventually lead to the crash. thanks to Pavel Roskin for fixing it and finding the root cause. https://bugzilla.redhat.com/show_bug.cgi?id=768639 Cc: stable@vger.kernel.org Cc: Pavel Roskin <proski@gnu.org> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-15Merge branch 'master' of ↵John W. Linville48-231/+272
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless Conflicts: net/mac80211/debugfs_sta.c net/mac80211/sta_info.h
2012-02-15mac80211: do not call rate control .tx_status before .rate_initFelix Fietkau1-1/+1
Most rate control implementations assume .get_rate and .tx_status are only called once the per-station data has been fully initialized. minstrel_ht crashes if this assumption is violated. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Tested-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-15mac80211: call rate control only after initJohannes Berg4-3/+6
There are situations where we don't have the necessary rate control information yet for station entries, e.g. when associating. This currently doesn't really happen due to the dummy station handling; explicitly disabling rate control when it's not initialised will allow us to remove dummy stations. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-15Bluetooth: Fix possible use after free in delete pathUlisses Furquim1-2/+2
We need to use the _sync() version for cancelling the info and security timer in the L2CAP connection delete path. Otherwise the delayed work handler might run after the connection object is freed. Signed-off-by: Ulisses Furquim <ulisses@profusion.mobi> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2012-02-15Bluetooth: Remove usage of __cancel_delayed_work()Ulisses Furquim1-3/+3
__cancel_delayed_work() is being used in some paths where we cannot sleep waiting for the delayed work to finish. However, that function might return while the timer is running and the work will be queued again. Replace the calls with safer cancel_delayed_work() version which spins until the timer handler finishes on other CPUs and cancels the delayed work. Signed-off-by: Ulisses Furquim <ulisses@profusion.mobi> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2012-02-15Bluetooth: Add missing QUIRK_NO_RESET test to hci_dev_do_closeJohan Hedberg1-1/+2
We should only perform a reset in hci_dev_do_close if the HCI_QUIRK_NO_RESET flag is set (since in such a case a reset will not be performed when initializing the device). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
2012-02-15Bluetooth: Fix RFCOMM session reference counting issueOctavian Purdila1-6/+12
There is an imbalance in the rfcomm_session_hold / rfcomm_session_put operations which causes the following crash: [ 685.010159] BUG: unable to handle kernel paging request at 6b6b6b6b [ 685.010169] IP: [<c149d76d>] rfcomm_process_dlcs+0x1b/0x15e [ 685.010181] *pdpt = 000000002d665001 *pde = 0000000000000000 [ 685.010191] Oops: 0000 [#1] PREEMPT SMP [ 685.010247] [ 685.010255] Pid: 947, comm: krfcommd Tainted: G C 3.0.16-mid8-dirty #44 [ 685.010266] EIP: 0060:[<c149d76d>] EFLAGS: 00010246 CPU: 1 [ 685.010274] EIP is at rfcomm_process_dlcs+0x1b/0x15e [ 685.010281] EAX: e79f551c EBX: 6b6b6b6b ECX: 00000007 EDX: e79f40b4 [ 685.010288] ESI: e79f4060 EDI: ed4e1f70 EBP: ed4e1f68 ESP: ed4e1f50 [ 685.010295] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 685.010303] Process krfcommd (pid: 947, ti=ed4e0000 task=ed43e5e0 task.ti=ed4e0000) [ 685.010308] Stack: [ 685.010312] ed4e1f68 c149eb53 e5925150 e79f4060 ed500000 ed4e1f70 ed4e1f80 c149ec10 [ 685.010331] 00000000 ed43e5e0 00000000 ed4e1f90 ed4e1f9c c149ec87 0000bf54 00000000 [ 685.010348] 00000000 ee03bf54 c149ec37 ed4e1fe4 c104fe01 00000000 00000000 00000000 [ 685.010367] Call Trace: [ 685.010376] [<c149eb53>] ? rfcomm_process_rx+0x6e/0x74 [ 685.010387] [<c149ec10>] rfcomm_process_sessions+0xb7/0xde [ 685.010398] [<c149ec87>] rfcomm_run+0x50/0x6d [ 685.010409] [<c149ec37>] ? rfcomm_process_sessions+0xde/0xde [ 685.010419] [<c104fe01>] kthread+0x63/0x68 [ 685.010431] [<c104fd9e>] ? __init_kthread_worker+0x42/0x42 [ 685.010442] [<c14dae82>] kernel_thread_helper+0x6/0xd This issue has been brought up earlier here: https://lkml.org/lkml/2011/5/21/127 The issue appears to be the rfcomm_session_put in rfcomm_recv_ua. This operation doesn't seem be to required as for the non-initiator case we have the rfcomm_process_rx doing an explicit put and in the initiator case the last dlc_unlink will drive the reference counter to 0. There have been several attempts to fix these issue: 6c2718d Bluetooth: Do not call rfcomm_session_put() for RFCOMM UA on closed socket 683d949 Bluetooth: Never deallocate a session when some DLC points to it but AFAICS they do not fix the issue just make it harder to reproduce. Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Signed-off-by: Gopala Krishna Murala <gopala.krishna.murala@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2012-02-15Bluetooth: silence lockdep warningOctavian Purdila3-7/+9
Since bluetooth uses multiple protocols types, to avoid lockdep warnings, we need to use different lockdep classes (one for each protocol type). This is already done in bt_sock_create but it misses a couple of cases when new connections are created. This patch corrects that to fix the following warning: <4>[ 1864.732366] ======================================================= <4>[ 1864.733030] [ INFO: possible circular locking dependency detected ] <4>[ 1864.733544] 3.0.16-mid3-00007-gc9a0f62 #3 <4>[ 1864.733883] ------------------------------------------------------- <4>[ 1864.734408] t.android.btclc/4204 is trying to acquire lock: <4>[ 1864.734869] (rfcomm_mutex){+.+.+.}, at: [<c14970ea>] rfcomm_dlc_close+0x15/0x30 <4>[ 1864.735541] <4>[ 1864.735549] but task is already holding lock: <4>[ 1864.736045] (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c1498bf7>] lock_sock+0xa/0xc <4>[ 1864.736732] <4>[ 1864.736740] which lock already depends on the new lock. <4>[ 1864.736750] <4>[ 1864.737428] <4>[ 1864.737437] the existing dependency chain (in reverse order) is: <4>[ 1864.738016] <4>[ 1864.738023] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}: <4>[ 1864.738549] [<c1062273>] lock_acquire+0x104/0x140 <4>[ 1864.738977] [<c13d35c1>] lock_sock_nested+0x58/0x68 <4>[ 1864.739411] [<c1493c33>] l2cap_sock_sendmsg+0x3e/0x76 <4>[ 1864.739858] [<c13d06c3>] __sock_sendmsg+0x50/0x59 <4>[ 1864.740279] [<c13d0ea2>] sock_sendmsg+0x94/0xa8 <4>[ 1864.740687] [<c13d0ede>] kernel_sendmsg+0x28/0x37 <4>[ 1864.741106] [<c14969ca>] rfcomm_send_frame+0x30/0x38 <4>[ 1864.741542] [<c1496a2a>] rfcomm_send_ua+0x58/0x5a <4>[ 1864.741959] [<c1498447>] rfcomm_run+0x441/0xb52 <4>[ 1864.742365] [<c104f095>] kthread+0x63/0x68 <4>[ 1864.742742] [<c14d5182>] kernel_thread_helper+0x6/0xd <4>[ 1864.743187] <4>[ 1864.743193] -> #0 (rfcomm_mutex){+.+.+.}: <4>[ 1864.743667] [<c1061ada>] __lock_acquire+0x988/0xc00 <4>[ 1864.744100] [<c1062273>] lock_acquire+0x104/0x140 <4>[ 1864.744519] [<c14d2c70>] __mutex_lock_common+0x3b/0x33f <4>[ 1864.744975] [<c14d303e>] mutex_lock_nested+0x2d/0x36 <4>[ 1864.745412] [<c14970ea>] rfcomm_dlc_close+0x15/0x30 <4>[ 1864.745842] [<c14990d9>] __rfcomm_sock_close+0x5f/0x6b <4>[ 1864.746288] [<c1499114>] rfcomm_sock_shutdown+0x2f/0x62 <4>[ 1864.746737] [<c13d275d>] sys_socketcall+0x1db/0x422 <4>[ 1864.747165] [<c14d42f0>] syscall_call+0x7/0xb Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2012-02-15Bluetooth: l2cap_set_timer needs jiffies as timeout valueAndrzej Kaczmarek1-4/+8
After moving L2CAP timers to workqueues l2cap_set_timer expects timeout value to be specified in jiffies but constants defined in miliseconds are used. This makes timeouts unreliable when CONFIG_HZ is not set to 1000. __set_chan_timer macro still uses jiffies as input to avoid multiple conversions from/to jiffies for sk_sndtimeo value which is already specified in jiffies. Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Ackec-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2012-02-15Bluetooth: Fix sk_sndtimeo initialization for L2CAP socketAndrzej Kaczmarek1-1/+1
sk_sndtime value should be specified in jiffies thus initial value needs to be converted from miliseconds. Otherwise this timeout is unreliable when CONFIG_HZ is not set to 1000. Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2012-02-15Bluetooth: Remove bogus inline declaration from l2cap_chan_connectJohan Hedberg1-1/+1
As reported by Dan Carpenter this function causes a Sparse warning and shouldn't be declared inline: include/net/bluetooth/l2cap.h:837:30 error: marked inline, but without a definition" Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
2012-02-15Bluetooth: Fix l2cap conn failures for ssp devicesPeter Hurley1-0/+4
Commit 330605423c fixed l2cap conn establishment for non-ssp remote devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security is tested (which was always returning failure on any subsequent security checks). However, this broke l2cap conn establishment for ssp remote devices when an ACL link was already established at SDP-level security. This fix ensures that encryption must be pending whenever authentication is also pending. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2012-02-09mac80211: Fix a rwlock bad magic bugMohammed Shafi Shajakhan1-2/+2
read_lock(&tpt_trig->trig.leddev_list_lock) is accessed via the path ieee80211_open (->) ieee80211_do_open (->) ieee80211_mod_tpt_led_trig (->) ieee80211_start_tpt_led_trig (->) tpt_trig_timer before initializing it. the intilization of this read/write lock happens via the path ieee80211_led_init (->) led_trigger_register, but we are doing 'ieee80211_led_init' after 'ieeee80211_if_add' where we register netdev_ops. so we access leddev_list_lock before initializing it and causes the following bug in chrome laptops with AR928X cards with the following script while true do sudo modprobe -v ath9k sleep 3 sudo modprobe -r ath9k sleep 3 done BUG: rwlock bad magic on CPU#1, wpa_supplicant/358, f5b9eccc Pid: 358, comm: wpa_supplicant Not tainted 3.0.13 #1 Call Trace: [<8137b9df>] rwlock_bug+0x3d/0x47 [<81179830>] do_raw_read_lock+0x19/0x29 [<8137f063>] _raw_read_lock+0xd/0xf [<f9081957>] tpt_trig_timer+0xc3/0x145 [mac80211] [<f9081f3a>] ieee80211_mod_tpt_led_trig+0x152/0x174 [mac80211] [<f9076a3f>] ieee80211_do_open+0x11e/0x42e [mac80211] [<f9075390>] ? ieee80211_check_concurrent_iface+0x26/0x13c [mac80211] [<f9076d97>] ieee80211_open+0x48/0x4c [mac80211] [<812dbed8>] __dev_open+0x82/0xab [<812dc0c9>] __dev_change_flags+0x9c/0x113 [<812dc1ae>] dev_change_flags+0x18/0x44 [<8132144f>] devinet_ioctl+0x243/0x51a [<81321ba9>] inet_ioctl+0x93/0xac [<812cc951>] sock_ioctl+0x1c6/0x1ea [<812cc78b>] ? might_fault+0x20/0x20 [<810b1ebb>] do_vfs_ioctl+0x46e/0x4a2 [<810a6ebb>] ? fget_light+0x2f/0x70 [<812ce549>] ? sys_recvmsg+0x3e/0x48 [<810b1f35>] sys_ioctl+0x46/0x69 [<8137fa77>] sysenter_do_call+0x12/0x2 Cc: <stable@vger.kernel.org> Cc: Gary Morain <gmorain@google.com> Cc: Paul Stewart <pstew@google.com> Cc: Abhijit Pradhan <abhijit@qca.qualcomm.com> Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com> Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Acked-by: Johannes Berg <johannes.berg@intel.com> Tested-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-08mac80211: do not call rate control .tx_status before .rate_initFelix Fietkau1-1/+1
Most rate control implementations assume .get_rate and .tx_status are only called once the per-station data has been fully initialized. minstrel_ht crashes if this assumption is violated. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Tested-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-08mac80211: rename mesh static path_lookup()Luis R. Rodriguez1-3/+3
If you want to use mesh support from mac80211 on a recent kernel on 2.6.24 you'll run into a name clash when compiling against include/linux/namei.h, so rename this routine. /home/mcgrof/tmp/compat-wireless-3.2.5-1/net/mac80211/mesh_pathtbl.c: At top level: /home/mcgrof/tmp/compat-wireless-3.2.5-1/net/mac80211/mesh_pathtbl.c:342:26: error: conflicting types for ‘path_lookup’ include/linux/namei.h:71:12: note: previous declaration of ‘path_lookup’ was here Although this could sit as a separate patch in compat-wireless it seems best to just merge upstream. Cc: Javier Cardona <javier@cozybit.com> Signed-off-by: Luis R. Rodriguez <mcgrof@frijolero.org> Acked-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-08mac80211: add #ifdef CONFIG_MAC80211_VERBOSE_DEBUG for a debug printkFelix Fietkau1-0/+2
When not debugging mac80211 code, station state transitions do not need to show up in the kernel log. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-06mac80211: call rate control only after initJohannes Berg4-3/+6
There are situations where we don't have the necessary rate control information yet for station entries, e.g. when associating. This currently doesn't really happen due to the dummy station handling; explicitly disabling rate control when it's not initialised will allow us to remove dummy stations. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-06mac80211: support hw scan while idleEliad Peller3-1/+7
Currently, mac80211 goes to idle-off before starting a scan. However, some devices that implement hw scan might not need going idle-off in order to perform a hw scan, and thus saving some energy and simplifying their state machine. (Note that this is also the case for sched scan - it currently doesn't make mac80211 go idle-off) Add a new flag to indicate support for hw scan while idle. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-06mac80211: off by one in mcs mask handlingDan Carpenter2-2/+2
"ridx" is used as an index into the mcs_mask[] array which has IEEE80211_HT_MCS_MASK_LEN elements. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-06cfg80211/mac80211: userspace peer authorization in IBSSAntonio Quartulli3-9/+19
If the IBSS network is RSN-protected, let userspace authorize the stations instead of adding them as AUTHORIZED by default. Signed-off-by: Antonio Quartulli <ordex@autistici.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-06mac80211: redesign auth/assocJohannes Berg8-1227/+1038
This is the second part of the auth/assoc redesign, the mac80211 part. This moves the auth/assoc code out of the work abstraction and into the MLME, so that we don't flip channels all the time etc. The only downside is that when we are associated, we need to drop the association in order to create a connection to another AP, but for most drivers this is actually desirable and the ability to do was never used by any applications. If we want to implement resource reservation with FT-OTA, we'd probably best do it with explicit R-O-C in wpa_s. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-06cfg80211: export cfg80211_ref_bssJohannes Berg2-5/+12
This is needed by mac80211 to keep a reference to a BSS alive for the auth process. Remove the old version of cfg80211_ref_bss() since it's not actually used. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-06cfg80211: stop tracking authenticated stateJohannes Berg5-333/+80
To track authenticated state seems to have been a design mistake in cfg80211. It is possible to have out of band authentication (FT), tracking multiple authentications caused more problems than it ever helped, and the implementation in mac80211 is too complex. Remove all this complexity, and let userspace do whatever it wants to, mac80211 can deal with that just fine. Association is still tracked of course, but authentication no longer is. Local auth state changes are thus no longer of value, so ignore them completely. This will also help implement SAE -- asking the driver to do an authentication is now almost equivalent to sending an authentication frame, with the exception of shared key authentication which is still handled completely. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-06mac80211: remove dummy STA supportJohannes Berg4-155/+38
The dummy STA support was added because I didn't want to change the driver API at the time. Now that we have state transitions triggering station add/remove in the driver, we only call add once a station reaches ASSOCIATED, so we can remove the dummy station stuff again. While at it, tighten the RX check and accept only port control (EAP) frames from the AP station if it's not associated yet -- in other cases there's no race. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-06mac80211: implement sta_add/sta_remove in sta_stateJohannes Berg4-19/+19
Instead of maintaining separate sta_add/sta_remove callsites, implement it in sta_state when the driver has no sta_state implementation. The only behavioural change this should cause is in secure mesh mode: with this the station entries will only be created after the stations are set to AUTH. Given which drivers support mesh, this seems to not be a problem. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-06mac80211: add sta_state callbackJohannes Berg7-28/+164
(based on Eliad's patch) Add a callback to notify the low-level driver whenever the state of a station changes. The driver is only notified when the station is actually in the mac80211 hash table, not for pre-insert state transitions. To allow the driver to replace sta_add/remove calls with this, call extra transitions with the NOTEXIST state. This callback can fail, so we need to be careful in handling it when a station is inserted, particularly in the IBSS case where we still keep the station entry around for mac80211 purposes. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-06mac80211: add NOTEXIST station stateJohannes Berg2-0/+3
This will be used by drivers later if they need to have stations inserted all the time, in mac80211 has no purpose, is never used and sta_state starts out in NONE. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-06mac80211: dont program keys for stations not uploadedJohannes Berg1-16/+14
If a station couldn't be uploaded to the driver but is still kept (only in IBSS mode) we still shouldn't try to program the keys for it into hardware; fix this bug by skipping the key upload in this case. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-06mac80211: simplify AP_VLAN handlingJohannes Berg5-33/+7
Setting keys and updating TKIP keys must use the BSS sdata (not AP_VLAN), so we translate. Move the translation into driver-ops wrappers instead of having it inline in the code to simplify the normal code flow. The same can be done for sta_add/remove which already does the translation in the wrapper. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-06mac80211: move managed mode station state modificationJohannes Berg1-14/+14
Move the station state modification right before insert, this just makes the current code more readable (you can tell that it's before insertion looking at a single screenful of code) right now, but some upcoming changes will require this. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-01mac80211: timeout a single frame in the rx reorder bufferEliad Peller1-1/+1
The current code checks for stored_mpdu_num > 1, causing the reorder_timer to be triggered indefinitely, but the frame is never timed-out (until the next packet is received) Signed-off-by: Eliad Peller <eliad@wizery.com> Cc: <stable@vger.kernel.org> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-01Merge branch 'master' of ↵John W. Linville6-20/+39
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless