12 Mar, 2011
1 commit
-
If dynamic_ps is disabled, enabling power save before the 4-way
handshake completes may delay the station from being authorized to
send/receive traffic, i.e. increase roaming times. It also may result in
a failed 4-way handshake depending on the AP's timing requirements and
beacon interval, and the station's listen interval.To fix this, prevent power save from being enabled while the station
isn't authorized and recalculate power save whenever the station's
authorized state changes.Signed-off-by: Jason Young
Acked-by: Johannes Berg
Signed-off-by: John W. Linville
26 Feb, 2011
1 commit
-
Is still possible to schedule conn_mon_timer after disassociate from
ieee80211_sta_tx_notify() and ieee80211_offchannel_ps_disable().Move disassociate check to ieee80211_sta_reset_conn_monitor() to cover
all these cases, and add unlikely since in most the time we call
ieee80211_sta_reset_conn_monitor() when associated.Signed-off-by: Stanislaw Gruszka
Signed-off-by: John W. Linville
24 Feb, 2011
1 commit
-
There is a race on sending a data frame before the tx completion
of nullfunc frame for enabling power save. As the data quickly
follows the nullfunc frame, the AP thinks that the station is out
of power save and continues to send the frames. Whereas in the
station, the nullfunc ack will be processed after the tx completion
of data frame and mac80211 goes to powersave. Thus the power
save state mismatch between the station and the AP causes some
data loss and some applications fail because of that. This patch
fixes this issue.Signed-off-by: Vivek Natarajan
Signed-off-by: John W. Linville
19 Feb, 2011
2 commits
-
Conflicts:
drivers/bluetooth/ath3k.c
drivers/bluetooth/btusb.c -
Low level driver could pass rx frames to us after disassociate, what
can lead to run conn_mon_timer by ieee80211_sta_rx_notify(). That
is obviously wrong, but nothing happens until we unload modules and
resources are used after free. If kernel debugging is enabled following
warning could be observed:WARNING: at lib/debugobjects.c:259 debug_print_object+0x65/0x70()
Hardware name: HP xw8600 Workstation
ODEBUG: free active (active state 0) object type: timer_list
Modules linked in: iwlagn(-) iwlcore mac80211 cfg80211 aes_x86_64 aes_generic fuse cpufreq_ondemand acpi_cpufreq freq_table mperf xt_physdev ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod uinput hp_wmi sparse_keymap sg wmi arc4 microcode serio_raw ecb tg3 shpchp rfkill ext4 mbcache jbd2 sr_mod cdrom sd_mod crc_t10dif firewire_ohci firewire_core crc_itu_t mptsas mptscsih mptbase scsi_transport_sas ahci libahci pata_acpi ata_generic ata_piix floppy nouveau ttm drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: cfg80211]
Pid: 13827, comm: rmmod Tainted: G W 2.6.38-rc4-wl+ #22
Call Trace:
[] ? warn_slowpath_common+0x7f/0xc0
[] ? warn_slowpath_fmt+0x46/0x50
[] ? debug_print_object+0x65/0x70
[] ? debug_check_no_obj_freed+0x125/0x210
[] ? debug_check_no_locks_freed+0xf7/0x170
[] ? kfree+0xc2/0x2f0
[] ? netdev_release+0x45/0x60
[] ? device_release+0x27/0xa0
[] ? kobject_release+0x8d/0x1a0
[] ? kobject_release+0x0/0x1a0
[] ? kref_put+0x37/0x70
[] ? kobject_put+0x27/0x60
[] ? netdev_run_todo+0x1ab/0x270
[] ? rtnl_unlock+0xe/0x10
[] ? ieee80211_unregister_hw+0x58/0x120 [mac80211]
[] ? iwl_pci_remove+0xdb/0x22a [iwlagn]
[] ? pci_device_remove+0x52/0x120
[] ? __device_release_driver+0x75/0xe0
[] ? driver_detach+0xd8/0xe0
[] ? bus_remove_driver+0x91/0x100
[] ? driver_unregister+0x62/0xa0
[] ? pci_unregister_driver+0x44/0xa0
[] ? iwl_exit+0x15/0x1c [iwlagn]
[] ? sys_delete_module+0x1a2/0x270
[] ? trace_hardirqs_on_thunk+0x3a/0x3f
[] ? system_call_fastpath+0x16/0x1bAcked-by: Johannes Berg
Signed-off-by: Stanislaw Gruszka
Signed-off-by: John W. Linville
10 Feb, 2011
1 commit
-
Some were indirectly set to NO_HT (zero), but I think
it's better to explicitly set it in case the enum ever
changes. In cfg.c, it seems the channel-type was just
ignored (and thus always set to NO_HT).Signed-off-by: Ben Greear
Signed-off-by: John W. Linville
08 Feb, 2011
1 commit
-
This allows users to tune the connection-loss algorithms
to be more or less lenient. In particular, larger
null-func retries helps when using lots of virtual
stations on a loaded network.Signed-off-by: Ben Greear
Signed-off-by: John W. Linville
04 Feb, 2011
1 commit
-
I have a netgear WNDR3700 that appears to have an off-by-four
bug in how it fills out the hti->control_chan (I configure the
AP to channel 11, it reports 15 as control_chan).Poke a message into the kernel logs to give users a
clue as to why they are not getting the expected
channel-type or rate.Signed-off-by: Ben Greear
Signed-off-by: John W. Linville
01 Feb, 2011
1 commit
-
PS should not be enabled if an infra AP vif exists in
the interface list. So while recalculating PS,
AP vif type should be taken into account.Reviewed-by: Johannes Berg
Signed-off-by: Rajkumar Manoharan
Signed-off-by: John W. Linville
22 Jan, 2011
1 commit
-
Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to
IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping
channel numbers in the 2GHz and 5GHz band we can't map from channel to
frequency without knowing the band. This is no problem as in most contexts we
know the band. In places where we don't know the band (and WEXT compatibility)
we assume the 2GHz band for channels below 14.This patch does not implement all channel to frequency mappings defined in
802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz
channels as well as 802.11y channels have been omitted.The following drivers have been updated to reflect the API changes:
iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx.
The drivers have been compile-tested only.Signed-off-by: Bruno Randolf
Signed-off-by: Brian Prodoehl
Acked-by: Luciano Coelho
Signed-off-by: John W. Linville
20 Jan, 2011
1 commit
-
Signed-off-by: Ben Greear
Signed-off-by: John W. Linville
08 Dec, 2010
2 commits
-
net/mac80211/mlme.c: In function 'ieee80211_sta_work':
net/mac80211/mlme.c:1981: warning: too many arguments for formatIntroduced by commit 04ac3c0ee2c773c321ec472d892635a20556f34d
("mac80211: speed up AP probing using nullfunc frames").Reported-by: Stephen Rothwell
Signed-off-by: Felix Fietkau
Signed-off-by: John W. Linville -
mac80211 uses pm_qos (/dev/network_latency) in order to determine the
dynamic ps timeout (or disable the dynamic-ps at all in some cases).commit ff616381 added a comparison for the current network_latency
against one high value (1900ms), and against the default value
(2000sec, rather than the commented 2sec).however, the representation of 1900ms was incorrect:
1900ms = 1900000us ( != 1900000000 )fix it by using USEC_TO_MSEC/SEC consts.
Signed-off-by: Eliad Peller
Signed-off-by: John W. Linville
07 Dec, 2010
2 commits
-
If the nullfunc frame used to probe the AP was not acked, there is no point
in waiting for the probe timeout, so advance to the next try (or disconnect)
immediately.
If we do reach the probe timeout without having received a tx status, the
connection is probably really bad and worth disconnecting.Signed-off-by: Felix Fietkau
Signed-off-by: John W. Linville -
ieee80211_is_nullfunc() implies ieee80211_is_data()
Signed-off-by: Felix Fietkau
Signed-off-by: John W. Linville
25 Nov, 2010
5 commits
-
Since nullfunc frames are transmitted as unicast frames, they're more
reliable than the broadcast probe requests, so we need fewer retries
to figure out whether the AP is really gone.Signed-off-by: Felix Fietkau
Signed-off-by: John W. Linville -
nullfunc frames are better for connection monitoring, because probe requests
are answered even if the AP has already dropped the connection, whereas
nullfunc frames from an unassociated station will trigger a disassoc/deauth
frame from the AP (WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA), which allows
the station to reconnect immediately instead of waiting until it attempts to
transmit the next unicast frame.This only works on hardware with reliable tx ACK reporting, any other hardware
needs to fall back to the probe request method.Signed-off-by: Felix Fietkau
Signed-off-by: John W. Linville -
Check the connection by probing the AP (either using nullfunc or a
probe request). If nullfunc probing is supported and the assoc is no
longer valid, the AP will send a disassoc/deauth immediately.Signed-off-by: Felix Fietkau
Signed-off-by: John W. Linville -
Instead of using a fixed 2 second timeout, calculate beacon loss interval
from the advertised beacon interval and a frame count. With this beacon
loss happens after N (default 7) consecutive frames are missed which
for a typical setup (100TU beacon interval) is ~700ms (or ~1/3 previous).Signed-off-by: Sam Leffler
Signed-off-by: Felix Fietkau
Signed-off-by: John W. Linville -
Signed-off-by: Paul Stewart
Signed-off-by: Felix Fietkau
Signed-off-by: John W. Linville
17 Nov, 2010
1 commit
-
Chipsets with hardware based connection monitoring need to autonomically
send directed probe-request frames to the AP (in the event of beacon loss,
for example.)For the hardware to be able to do this, it requires a template for the frame
to transmit to the AP, filled in with the BSSID and SSID of the AP, but also
the supported rate IE's.This patch adds a function to mac80211, which allows the hardware driver to
fetch this template after association, so it can be configured to the hardware.Signed-off-by: Juuso Oikarinen
Acked-by: Johannes Berg
Signed-off-by: John W. Linville
12 Oct, 2010
1 commit
-
Old messages didn't mention the device in question.
Signed-off-by: Ben Greear
Signed-off-by: John W. Linville
07 Oct, 2010
1 commit
-
When roaming while we have active BA session,
we can end up transmitting delBA frames to
the old AP while we're already on the new AP's
channel, which can cause warnings.Simply avoid sending those frames, but still
tear down the internal session state, since
they are not really necessary anyway as we
will implicitly disassociate when sending the
association to the new AP.Signed-off-by: Johannes Berg
Acked-by: Luis R. Rodriguez
Signed-off-by: John W. Linville
06 Oct, 2010
3 commits
-
Be consistent and use the wk->chan instead of the
local->hw.conf.channel for the association done work.
This prevents any possible races against channel changes
while we run this work.In the case that the race did happen we would be initializing
the bit rates for the new AP under the assumption of a wrong
channel and in the worst case, wrong band. This could lead
to trying to assuming we could use CCK frames on 5 GHz, for
example.This patch has a fix for kernels >= v2.6.34
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez
Signed-off-by: John W. Linville -
The locking around ieee80211_recalc_smps is
buggy -- it cannot acquire another interface's
mutex while the iflist mutex is held because
another code path could be holding the iface
mutex and trying to acquire the iflist mutex.But the locking is also unnecessary, we only
check "ifmgd->associated" as a bool, and don't
use the pointer (in check_mgd_smps).Reported-by: Ben Greear
Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville -
On association to an AP, after receiving beacons, the beacon_crc value is set.
The beacon_crc value is not reset in disassociation, but the BSS data may be
expired at a later point. When associating again, it's possible that a
beacon for the AP is not received, resulting in the beacon_ies to remain NULL.After association, further beacons will not update the beacon data, as the
crc value of the beacon has not changed, and the beacon_crc still holds a
value matching the beacon. The beacon_ies will remain forever null.One of the results of this is that WLAN power save cannot be entered, the STA
will remain foreven in active mode.Fix this by adding a validation flag for the beacon_crc, which is cleared on
association.Signed-off-by: Juuso Oikarinen
Acked-by: Johannes Berg
Signed-off-by: John W. Linville
29 Sep, 2010
1 commit
-
The WMM parameter configuration function (ieee80211_sta_wmm_params) only
configures the WMM parameters to the driver is the wmm_last_param_set
counter value is changed by the AP.The wmm_last_param_set is initialized to -1 on association in order to ensure
the configuration is made to the driver at least once on association, but
currently this initialization is done *after* the WMM parameter configuration
function was called.This leads to unreliability in the driver getting properly configured on first
association (depending on what counter value the AP happens to use.) When
disassociating (the wmm default parameters are configured to the driver) and
then reassociating, due to the above the WMM configuration is not set to the
driver at all.On drivers without beacon filtering the problem is corrected by later beacons,
but on drivers with beacon filtering the WMM will remain permanently incorrectly
configured.Fix this by moving the initialization of wmm_last_param_set to -1 before
ieee80211_sta_wmm_params is called on association.Signed-off-by: Juuso Oikarinen
Acked-by: Johannes Berg
Signed-off-by: John W. Linville
17 Sep, 2010
5 commits
-
Some buggy APs do not respond to unicast probe requests
or send unicast probe requests very delayed so in the
worst case we should try to send broadcast probe requests,
otherwise we can get disconnected from these APs.Even if drivers do not have filters to disregard probe
responses from foreign APs mac80211 will only process
probe responses from our associated AP for re-arming
connection monitoring.We need to do this since the beacon monitor does not
push back the connection monitor by design so even if we
are getting beacons from these type of APs our connection
monitor currently relies heavily on the way the probe
requests are received on the AP. An example of an AP
affected by this is the Nexus One, but this has also been
observed with random APs.We can probably optimize this later by using null funcs
instead of probe requests.For more details refer to:
http://code.google.com/p/chromium-os/issues/detail?id=5715
This patch has fixes for stable kernels [2.6.35+].
Cc: stable@kernel.org
Cc: Paul Stewart
Cc: Amod Bodas
Signed-off-by: Luis R. Rodriguez
Signed-off-by: John W. Linville -
This will be used by other components next. The beacon
monitor was added as of 2.6.34 so these fixes are applicable
only to kernels >= 2.6.34.Cc: stable@kernel.org
Cc: Paul Stewart
Cc: Amod Bodas
Signed-off-by: Luis R. Rodriguez
Signed-off-by: John W. Linville -
Upon beacon loss we send probe requests after 30 seconds of idle
time and we wait for each probe response 1/2 second. We send a
total of 3 probe requests before giving up on the AP. In the case
that we reset the connection idle monitor we should reset the probe
requests count to 0. Right now this won't help in any way but
the next patch will.This patch has fixes for stable kernel [2.6.35+].
Cc: stable@kernel.org
Cc: Paul Stewart
Cc: Amod Bodas
Signed-off-by: Luis R. Rodriguez
Signed-off-by: John W. Linville -
This will be used in another place later. The connection
monitor was added as of 2.6.35 so these fixes will be
applicable to >= 2.6.35.Cc: stable@kernel.org
Cc: Paul Stewart
Cc: Amod Bodas
Signed-off-by: Luis R. Rodriguez
Signed-off-by: John W. Linville -
Instead of using a WARN_ON(!mutex_is_locked())
use lockdep_assert_held() which compiles away
completely when lockdep isn't enabled, and
also is a more accurate assertion since it
checks that the current thread is holding the
mutex.Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville
01 Sep, 2010
2 commits
-
The signal strength value in a single RX frame is not that reliable,
so it is better to delay start of CQM events until there is a real
average signal strength from more than a single Beacon frame
available.Signed-off-by: Jouni Malinen
Signed-off-by: John W. Linville -
The ave_beacon_signal value uses 1/16 dB unit and as such, must be
initialized with the signal level of the first Beacon frame multiplied
by 16. This fixes an issue where the initial CQM events are reported
incorrectly with a burst of events while the running average
approaches the correct value after the incorrect initialization. This
could cause user space -based roaming decision process to get quite
confused at the moment when we would like to go through authentication
and DHCP.Cc: stable@kernel.org
Signed-off-by: Jouni Malinen
Signed-off-by: John W. Linville
28 Aug, 2010
2 commits
-
There's a lot of redundant code in mac80211's
interface cleanup/down, for example freeing
AP beacons is done both when the interface is
set DOWN as well as when it is torn down, of
which only the former has any effect.Also, a bunch of things should be closer to
where they matter, like the MLME timers that
we should cancel when disassociating, rather
than only when the interface is set DOWN.Clean up all this code.
Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville -
Some vendor specified mechanisms for 802.1X-style
functionality use a different protocol than EAP
(even if EAP is vendor-extensible). Support this
in mac80211 via the cfg80211 API for it.Signed-off-by: Johannes Berg
Signed-off-by: Juuso Oikarinen
Signed-off-by: John W. Linville
26 Aug, 2010
1 commit
-
Standardize logging messages from
printk(KERN_ "%s: " fmt , wiphy_name(foo), args);
to
wiphy_(foo, fmt, args);Signed-off-by: Joe Perches
Signed-off-by: John W. Linville
17 Aug, 2010
3 commits
-
Sometimes drivers have more information than the
stack about how their antennas/chains are used,
and may require that the SM PS mode be changed.
This could happen, for example, when detecting
that the user disconnected an antenna. Thus this
patch introduces API to allow drivers to request
SM PS mode changes.Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville -
Sometimes we don't just need to know whether or
not the device is idle, but also per interface.
This adds that reporting capability to mac80211.Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville -
Having both scan and work mutexes is not just
a bit too fine grained, it also creates issues
when there's code that needs both since they
then need to be acquired in the right order,
which can be hard to do.Therefore, use just a single mutex for both.
Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville