22 Feb, 2012
2 commits
-
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:
[] warn_slowpath_common+0x72/0xa0
[] ?
ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]
[] ?
ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]
[] warn_slowpath_null+0x22/0x30
[]
ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]
[] __ieee80211_recalc_idle+0x113/0x430
[mac80211]
[] ieee80211_do_open+0x156/0x7e0 [mac80211]
[] ?
ieee80211_check_concurrent_iface+0x25/0x180 [mac80211]
[] ? raw_notifier_call_chain+0x1f/0x30
[] ieee80211_open+0x40/0x80 [mac80211]
[] __dev_open+0x96/0xe0
[] ? _raw_spin_unlock_bh+0x35/0x40
[] __dev_change_flags+0x109/0x170
[] dev_change_flags+0x23/0x60
[] devinet_ioctl+0x6a0/0x770ieee80211 phy0: device no longer idle - in use
Cc: Eliad Peller
Signed-off-by: Mohammed Shafi Shajakhan
Signed-off-by: John W. Linville -
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=768639Cc: stable@vger.kernel.org
Cc: Pavel Roskin
Signed-off-by: Mohammed Shafi Shajakhan
Signed-off-by: John W. Linville
16 Feb, 2012
2 commits
-
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
Tested-by: Arend van Spriel
Signed-off-by: John W. Linville -
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
Signed-off-by: John W. Linville
10 Feb, 2012
1 commit
-
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
scriptwhile true
do
sudo modprobe -v ath9k
sleep 3
sudo modprobe -r ath9k
sleep 3
doneBUG: rwlock bad magic on CPU#1, wpa_supplicant/358, f5b9eccc
Pid: 358, comm: wpa_supplicant Not tainted 3.0.13 #1
Call Trace:[] rwlock_bug+0x3d/0x47
[] do_raw_read_lock+0x19/0x29
[] _raw_read_lock+0xd/0xf
[] tpt_trig_timer+0xc3/0x145 [mac80211]
[] ieee80211_mod_tpt_led_trig+0x152/0x174 [mac80211]
[] ieee80211_do_open+0x11e/0x42e [mac80211]
[] ? ieee80211_check_concurrent_iface+0x26/0x13c [mac80211]
[] ieee80211_open+0x48/0x4c [mac80211]
[] __dev_open+0x82/0xab
[] __dev_change_flags+0x9c/0x113
[] dev_change_flags+0x18/0x44
[] devinet_ioctl+0x243/0x51a
[] inet_ioctl+0x93/0xac
[] sock_ioctl+0x1c6/0x1ea
[] ? might_fault+0x20/0x20
[] do_vfs_ioctl+0x46e/0x4a2
[] ? fget_light+0x2f/0x70
[] ? sys_recvmsg+0x3e/0x48
[] sys_ioctl+0x46/0x69
[] sysenter_do_call+0x12/0x2Cc:
Cc: Gary Morain
Cc: Paul Stewart
Cc: Abhijit Pradhan
Cc: Vasanthakumar Thiagarajan
Cc: Rajkumar Manoharan
Acked-by: Johannes Berg
Tested-by: Mohammed Shafi Shajakhan
Signed-off-by: Mohammed Shafi Shajakhan
Signed-off-by: John W. Linville
02 Feb, 2012
1 commit
-
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
Cc:
Acked-by: Johannes Berg
Signed-off-by: John W. Linville
25 Jan, 2012
2 commits
-
__ieee80211_recalc_idle() iterates through the vifs,
sets bss_conf.idle = true if they are disconnected,
and increases "count" if they are not (which later
gets evaluated in order to determine whether the
device is idle).However, the loop doesn't set bss_conf.idle = false
(along with increasing "count"), causing the device
idle state and the vif idle state to get out of sync
in some cases.Signed-off-by: Eliad Peller
Signed-off-by: John W. Linville -
Commit 13c40c5 ("mac80211: Add HT operation modes for IBSS") broke
ibss operation by mistakenly removing the local->oper_channel
update (causing ibss to start on the wrong channel). fix it.Signed-off-by: Eliad Peller
Acked-by: Simon Wunderlich
Signed-off-by: John W. Linville
19 Jan, 2012
3 commits
-
When deauth is requested while an auth or assoc
work item is in progress, we currently delete it
without regard for any state it might need to
clean up. Fix it by cleaning up for those items.In the case Pontus found, the problem manifested
itself as such:authenticate with 00:23:69:aa:dd:7b (try 1)
authenticated
failed to insert Dummy STA entry for the AP (error -17)
deauthenticating from 00:23:69:aa:dd:7b by local choice (reason=2)It could also happen differently if the driver
uses the tx_sync callback.We can't just call the ->done() method of the work
items because that will lock up due to the locking
in cfg80211. This fix isn't very clean, but that
seems acceptable since I have patches pending to
remove this code completely.Cc: stable@vger.kernel.org
Reported-by: Pontus Fuchs
Tested-by: Pontus Fuchs
Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville -
Use local->tx_headroom instad of local->hw.extra_tx_headroom.
local->tx_headroom is the max of hw.extra_tx_headroom required by the
driver and the headroom required by mac80211 for status reporting. On
drivers where hw.extra_tx_headroom is smaller than what mac80211
requires (e.g. ath5k), we would not reserve sufficient buffer space to
report tx status.Also, don't reserve local->tx_headroom + local->hw.extra_tx_headroom.
Reported-by: Simon Morgenthaler
Reported-by: Kai Scharwies
Signed-off-by: Javier Cardona
Signed-off-by: John W. Linville -
Since stations moved into a virtual interface
subdirectory, this link has been broken. Fix it.Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville
17 Jan, 2012
3 commits
-
All other code paths in sta_unblock synchronize with the network
softirq by using local_bh_disable/enable. Do the same around
ieee80211_sta_ps_deliver_wakeup.Signed-off-by: Helmut Schaa
Signed-off-by: John W. Linville -
In function ieee80211_tx_h_encrypt the var info was
initialized from tx->skb, since the fucntion
is called after the function ieee80211_tx_h_fragment
tx->skb is not valid anymore.Signed-off-by: Yoni Divinsky
Signed-off-by: John W. Linville -
We may leak the 'fwd_skb' we skb_copy() in ieee80211_rx_h_mesh_fwding() if
we take the 'else' branch in the 'if' statement just below. If we take
that branch we'll end up returning from the function and since we've not
assigned 'fwd_skb' to anything at that point, we leak it when the variable
goes out of scope.The simple fix seems to be to just kfree_skb(fwd_skb); just before we
return. That is what this patch does.Signed-off-by: Jesper Juhl
Signed-off-by: John W. Linville
14 Jan, 2012
1 commit
-
When userspace attempts to authorize a station
that is already authorized, nothing happens as
you'd expect. Similarly, when it unauthorizes
a station that is associated, nothing happens.However, when it unauthorizes a station that
isn't even associated yet, we erroneously try
to move the station to associated. This seems
to happen occasionally as a result of a race
when wpa_supplicant attempts to unauthorize
the port in managed mode. Particularly with my
new patches to keep stations, it can then move
a station into ASSOCIATED state before we have
really associated, which is really confusing.I introduced this bug in
"mac80211: refactor station state transitions"Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville
13 Jan, 2012
1 commit
-
commit a9b3cd7f32 (rcu: convert uses of rcu_assign_pointer(x, NULL) to
RCU_INIT_POINTER) did a lot of incorrect changes, since it did a
complete conversion of rcu_assign_pointer(x, y) to RCU_INIT_POINTER(x,
y).We miss needed barriers, even on x86, when y is not NULL.
Signed-off-by: Eric Dumazet
CC: Stephen Hemminger
CC: Paul E. McKenney
Signed-off-by: David S. Miller
12 Jan, 2012
1 commit
-
Since:
commit 816c04fe7ef01dd9649f5ccfe796474db8708be5
Author: Christian Lamparter
Date: Sat Apr 30 15:24:30 2011 +0200mac80211: consolidate MIC failure report handling
is possible to that we dereference rx->key == NULL when driver set
RX_FLAG_MMIC_STRIPPED and not RX_FLAG_IV_STRIPPED and we are in
promiscuous mode. This happen with rt73usb and rt61pci at least.Before the commit we always check rx->key against NULL, so I assume
fix should be done in mac80211 (also mic_fail path has similar check).References:
https://bugzilla.redhat.com/show_bug.cgi?id=769766
http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2012-January/004395.htmlCc: stable@vger.kernel.org # 3.0+
Reported-by: Stuart D Gathman
Reported-by: Kai Wohlfahrt
Signed-off-by: Stanislaw Gruszka
Signed-off-by: John W. Linville
05 Jan, 2012
8 commits
-
…wireless-next into for-davem
Conflicts:
drivers/net/wireless/b43legacy/dma.c -
ieee80211_offchannel_enable_all_ps function is no longer used
and looks like its logic is extensively handled in
ieee80211_offchannel_stop_vifsSigned-off-by: Mohammed Shafi Shajakhan
Signed-off-by: John W. Linville -
Ideally, hardware/firmware initialization is complete after the
drv_start routine. In mac80211 restart code (ieee80211_reconfig),
defer calling the driver commands i.e. setup fragmentation
threshold, rts threshold and coverage class till drv_start
routine is called.Signed-off-by: Nishant Sarmukadam
Signed-off-by: Yogesh Ashok Powarv2: Removed extra blank line added.
Signed-off-by: John W. Linville -
this is being recently introduced by the commit
a85e1d55974646a442d95911e3f7d7a891ea9ac5Cc: Paul Stewart
Signed-off-by: Mohammed Shafi Shajakhan
Signed-off-by: John W. Linville -
kernel panic occurs when we create an IBSS mode and leave it for
sometime without any joiner and this is introduced by the
commit ec2b774e7c91094d8c00de579646f1162b87b01e where we don't
put proper braces for 'list_for_each_entry_safe' and we pass an
invalid 'sta' pointer to __sta_info_destroyEIP is at __list_add+0xe/0xa0
EAX: f3b63db4 EBX: 00000000 ECX: eab88c1c EDX: 00000000
ESI: 00000000 EDI: 00000246 EBP: f3b63d80 ESP: f3b63d58
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process kworker/u:2 (pid: 198, ti=f3b62000 task=f3afbea0
task.ti=f3b62000)
Stack:
00000000 00000000 f9ef9821 00000000 00000000 eab88c30
f3b63d80 c017f623
eab88bf0 eab88bf0 f3b63dd0 c066f925 00000000 00000002
00000000 f9ef9821
f3b63da0 c0180a2b eab88c1c eab88c30 00000002 f3afbea0
eab88bf4 f3b63db4
Call Trace:
[] ? __ieee80211_stop_tx_ba_session+0x31/0x60
[mac80211]
[] ? debug_mutex_add_waiter+0x23/0x60
[] __mutex_lock_common+0xd5/0x390
[] ? __ieee80211_stop_tx_ba_session+0x31/0x60
[mac80211]
[] ? trace_hardirqs_off+0xb/0x10
[] mutex_lock_nested+0x47/0x60
[] ? __ieee80211_stop_tx_ba_session+0x31/0x60
[mac80211]
[] __ieee80211_stop_tx_ba_session+0x31/0x60
[mac80211]
[] ieee80211_sta_tear_down_BA_sessions+0x39/0x60 [mac80211]
[] __sta_info_destroy+0x57/0x780 [mac80211]
[] ieee80211_sta_expire+0x93/0xb0 [mac80211]
[] ieee80211_ibss_work+0x2d6/0x530 [mac80211]Cc: Marek Lindner
Signed-off-by: Mohammed Shafi Shajakhan
Signed-off-by: John W. Linville -
when we run high bandwidth UDP traffic and we trigger a scan, the scan
state machine seems to be looping in SUSPEND->RESUME->DECISION->SUSPEND
and SET_CHANNEL seems to be never called as 'tx_empty' is never true
while running UDP traffic. fix this by settting SET_CHANNEL state when
we get into RESUME state.Cc: Leela Kella
Signed-off-by: Mohammed Shafi Shajakhan
Signed-off-by: John W. Linville -
If the vif is stopped while it is offchannel (e.g. right
after p2p negotiation) the SDATA_STATE_OFFCHANNEL flag
is never get cleared, resulting in various bad effects
(e.g. GO can't start beaconing).Fix it by clearing the SDATA_STATE_OFFCHANNEL flag
even if the vif is stopped.Signed-off-by: Eliad Peller
Signed-off-by: John W. Linville -
This seems to not serve any purpose anymore, at least all frame
processing afterwards seems to be able to deal with QoS frames. So,
let's save the expensive memmove and just leave the QoS header in the
802.11 frame for further processing.Signed-off-by: Helmut Schaa
Signed-off-by: John W. Linville
04 Jan, 2012
1 commit
-
…wireless-next into for-davem
Conflicts:
drivers/net/wireless/b43/dma.c
drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
22 Dec, 2011
2 commits
-
When mac80211 relays a frame from STA1 to STA2 in AP mode it will get
re-classified in the tx path. Unfortunately the frame protocol field
is always set to ETH_P_8023 while the classification only kicks in
for ETH_P_IP. Hence, a high priority frame from STA1 will be send to
STA2 as best effort.Instead of running classification on the frame just use the same
priority as STA1 did. Do this by adding 256 to the skb->priority
to allow cfg80211_classify8021d to shortcut frame classification.Signed-off-by: Helmut Schaa
Signed-off-by: John W. Linville -
The IBSS merge code calls ieee80211_sta_expire() with a relatively
short expire timeout that purges other clients prematurely. The
expire function has to check that only the clients belonging to
the vif in question are purged.Signed-off-by: Marek Lindner
Signed-off-by: John W. Linville
20 Dec, 2011
5 commits
-
DaveM said:
Please, this kind of stuff rots forever and not using bool properly
drives me crazy.Joe Perches gave me the spatch script:
@@
bool b;
@@
-b = 0
+b = false
@@
bool b;
@@
-b = 1
+b = trueI merely installed coccinelle, read the documentation and took credit.
Signed-off-by: Rusty Russell
Signed-off-by: David S. Miller -
The commit 42624d4913a00219a8fdbb4bafd634d1d843be85
created following sparse warning
>net/mac80211/sta_info.c:965:24: warning: incorrect type in assignment (different address spaces)
>net/mac80211/sta_info.c:965:24: expected struct tid_ampdu_tx *tid_tx
>net/mac80211/sta_info.c:965:24: got struct tid_ampdu_tx [noderef] *Making use of rcu_dereference_protected to fix the problem.
V2:
- Replacing rcu_dereference with rcu_dereference_protected
as suggested by Johannes.
- Adding mutex_lock/unlock to satisfy the condition at
rcu_dereference_protectedCc: Nishant Sarmukadam
Reported-by: Johannes Berg
Signed-off-by: Yogesh Ashok Powar
Signed-off-by: John W. Linville -
When a peer changes SMPS state we should update
rate control so it doesn't have to detect it by
itself. It can't detect "dynamic" mode anyway
since that just requires rts-cts handshaking.Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville -
If station info contains a beacon loss count, return
it to userspace.Signed-off-by: Paul Stewart
Signed-off-by: John W. Linville -
Currently code allows three (HT_AGG_MAX_RETRIES) unanswered addba
requests. When this limit is reached aggregation is turned off for
given TID permanently. This doesn't seem right: three requests is
not that much, some 'blackout' can happen, but effect of it affects
whole connection indefinitely.
This patch increases number of retries to 15. Also, when there have
been 3 or more retries it splits further retries apart by 15 seconds
instead of sending them in very short period of time.Signed-off-by: Nikolay Martynov
Signed-off-by: John W. Linville
16 Dec, 2011
7 commits
-
we found that power save is not getting enabled when we do
change interface in this order STA->IBSS->STA. this is
because ieee80211_setup_sdata clears type-dependent unionReported-by: Leela Kella
Signed-off-by: Mohammed Shafi Shajakhan
Signed-off-by: John W. Linville -
Signed-off-by: Mohammed Shafi Shajakhan
Signed-off-by: John W. Linville -
Currently BAR, ADDBA and DELBA frames are always sent using AC_VO. If
the TID for which a BA session is established is assigned to a different
queue BAR, ADDBA and DELBA frames can "overtake" frames of the according
BA session.Hence, always put BA session related frames into the same queue as the
BA sessions data frames.Signed-off-by: Helmut Schaa
Signed-off-by: John W. Linville -
Now that IBSS no longer needs to insert stations
from atomic context, we can get rid of all the
special cases for that, and even get rid of the
sta_lock (though it needs to stay as tim_lock.)This makes the station management code much more
straight-forward.Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville -
In order to notify drivers and simplify the station
management code, defer IBSS station insertion to a
work item and don't do it directly while receiving
a frame.This increases the complexity in IBSS a little bit,
but it's pretty straight forward and it allows us
to reduce the station management complexity (next
patch) considerably.Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville -
No real changes, just note that they are const.
Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville -
Currently, each AP interface will send multicast
traffic if any interface has a station entry even
if that station entry is allocated only. With the
new station state management we can easily fix it
by adding a counter that counts each authorized
station only and send multicast traffic only when
the correct interface has at least one authorized
station.Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville