summaryrefslogtreecommitdiffstats
path: root/net/mac80211/mlme.c
Commit message (Collapse)AuthorAgeFilesLines
* mac80211: better fix for conn_mon_timer running after disassociateStanislaw Gruszka2011-02-251-6/+3
| | | | | | | | | | | | 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 <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Fix a race on enabling power save.Vivek Natarajan2011-02-231-1/+13
| | | | | | | | | | | | | | | 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 <vnatarajan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Merge ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6John W. Linville2011-02-181-0/+6
|\ | | | | | | | | | | Conflicts: drivers/bluetooth/ath3k.c drivers/bluetooth/btusb.c
| * mac80211: fix conn_mon_timer running after disassociateStanislaw Gruszka2011-02-181-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: [<ffffffff810649cf>] ? warn_slowpath_common+0x7f/0xc0 [<ffffffff81064ac6>] ? warn_slowpath_fmt+0x46/0x50 [<ffffffff81226fc5>] ? debug_print_object+0x65/0x70 [<ffffffff81227625>] ? debug_check_no_obj_freed+0x125/0x210 [<ffffffff8109ebd7>] ? debug_check_no_locks_freed+0xf7/0x170 [<ffffffff81156092>] ? kfree+0xc2/0x2f0 [<ffffffff813ec5c5>] ? netdev_release+0x45/0x60 [<ffffffff812f1067>] ? device_release+0x27/0xa0 [<ffffffff81216ddd>] ? kobject_release+0x8d/0x1a0 [<ffffffff81216d50>] ? kobject_release+0x0/0x1a0 [<ffffffff812183b7>] ? kref_put+0x37/0x70 [<ffffffff81216c57>] ? kobject_put+0x27/0x60 [<ffffffff813d5d1b>] ? netdev_run_todo+0x1ab/0x270 [<ffffffff813e771e>] ? rtnl_unlock+0xe/0x10 [<ffffffffa0581188>] ? ieee80211_unregister_hw+0x58/0x120 [mac80211] [<ffffffffa0377ed7>] ? iwl_pci_remove+0xdb/0x22a [iwlagn] [<ffffffff8123cde2>] ? pci_device_remove+0x52/0x120 [<ffffffff812f5205>] ? __device_release_driver+0x75/0xe0 [<ffffffff812f5348>] ? driver_detach+0xd8/0xe0 [<ffffffff812f4111>] ? bus_remove_driver+0x91/0x100 [<ffffffff812f5b62>] ? driver_unregister+0x62/0xa0 [<ffffffff8123d194>] ? pci_unregister_driver+0x44/0xa0 [<ffffffffa0377df5>] ? iwl_exit+0x15/0x1c [iwlagn] [<ffffffff810ab492>] ? sys_delete_module+0x1a2/0x270 [<ffffffff81498889>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff8100bf42>] ? system_call_fastpath+0x16/0x1b Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: Properly set work-item channel-type.Ben Greear2011-02-091-0/+2
| | | | | | | | | | | | | | | | | | | | 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 <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: Make some mlme timers module paramaters.Ben Greear2011-02-071-11/+23
| | | | | | | | | | | | | | | | | | | | 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 <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: Warn users if HT fails because of freq mismatch.Ben Greear2011-02-031-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: disable power save if an infra AP vif existsRajkumar Manoharan2011-01-311-0/+8
| | | | | | | | | | | | | | | | | | | | 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 <johannes@sipsolutions.net> Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | cfg80211: Extend channel to frequency mapping for 802.11jBruno Randolf2011-01-211-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <br1@einfach.org> Signed-off-by: Brian Prodoehl <bprodoehl@gmail.com> Acked-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: Show max retry-counts in kernel messages.Ben Greear2011-01-191-4/+4
|/ | | | | Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: fix a compiler warningFelix Fietkau2010-12-071-2/+1
| | | | | | | | | | | | net/mac80211/mlme.c: In function 'ieee80211_sta_work': net/mac80211/mlme.c:1981: warning: too many arguments for format Introduced by commit 04ac3c0ee2c773c321ec472d892635a20556f34d ("mac80211: speed up AP probing using nullfunc frames"). Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: fix dynamic-ps/pm_qos magic numbersEliad Peller2010-12-071-4/+5
| | | | | | | | | | | | | | | | | 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 <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: speed up AP probing using nullfunc framesFelix Fietkau2010-12-061-25/+68
| | | | | | | | | | | 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 <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: remove a redundant checkFelix Fietkau2010-12-061-2/+1
| | | | | | | ieee80211_is_nullfunc() implies ieee80211_is_data() Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: reduce the number of retries for nullfunc probingFelix Fietkau2010-11-241-1/+8
| | | | | | | | | 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 <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: use nullfunc instead of probe request for connection monitoringFelix Fietkau2010-11-241-26/+66
| | | | | | | | | | | | | | | 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 <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: probe the AP when resumingFelix Fietkau2010-11-241-0/+1
| | | | | | | | | 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 <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: calculate beacon loss time accuratelyFelix Fietkau2010-11-241-4/+12
| | | | | | | | | | | 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 <sleffler@chromium.org> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: restart beacon miss timer on system resume from suspendFelix Fietkau2010-11-241-0/+1
| | | | | | Signed-off-by: Paul Stewart <pstew@google.com> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Add function to get probe request template for current APJuuso Oikarinen2010-11-161-0/+24
| | | | | | | | | | | | | | | | | 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 <juuso.oikarinen@nokia.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Improve mlme probe response log messages.Ben Greear2010-10-111-7/+11
| | | | | | | Old messages didn't mention the device in question. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: avoid transmitting delBA to old APJohannes Berg2010-10-061-9/+9
| | | | | | | | | | | | | | | | | 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 <johannes.berg@intel.com> Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: fix channel assumption for association done workLuis R. Rodriguez2010-10-051-3/+3
| | | | | | | | | | | | | | | | | | | 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 <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: fix deadlock with multiple interfacesJohannes Berg2010-10-051-1/+1
| | | | | | | | | | | | | | | | 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 <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Add validity check for beacon_crc valueJuuso Oikarinen2010-10-051-2/+5
| | | | | | | | | | | | | | | | | | | | | 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 <juuso.oikarinen@nokia.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Fix WMM driver queue configurationJuuso Oikarinen2010-09-281-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <juuso.oikarinen@nokia.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: send last 3/5 probe requests as unicastLuis R. Rodriguez2010-09-161-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: make the beacon monitor available externallyLuis R. Rodriguez2010-09-161-4/+4
| | | | | | | | | | | | 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 <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: reset probe send counter upon connection timer resetLuis R. Rodriguez2010-09-161-0/+4
| | | | | | | | | | | | | | | | | 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 <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: add helper for reseting the connection monitorLuis R. Rodriguez2010-09-161-5/+10
| | | | | | | | | | | | 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 <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* cfg80211/mac80211: use lockdep_assert_heldJohannes Berg2010-09-161-1/+1
| | | | | | | | | | | | 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 <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Do not generate CQM events based on first Beacon framesJouni Malinen2010-08-311-0/+9
| | | | | | | | | | 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 <j@w1.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Fix signal strength average initialization for CQM eventsJouni Malinen2010-08-311-1/+1
| | | | | | | | | | | | | | | 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 <j@w1.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: clean up ifdown/cleanup pathsJohannes Berg2010-08-271-0/+5
| | | | | | | | | | | | | | | | | | 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 <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: allow changing port control protocolJohannes Berg2010-08-271-0/+3
| | | | | | | | | | | 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 <johannes.berg@intel.com> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* net/mac80211: Use wiphy_<level>Joe Perches2010-08-251-8/+9
| | | | | | | | | | Standardize logging messages from printk(KERN_<level> "%s: " fmt , wiphy_name(foo), args); to wiphy_<level>(foo, fmt, args); Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: allow drivers to request SM PS mode changeJohannes Berg2010-08-161-0/+3
| | | | | | | | | | | | | 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 <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: per interface idle notificationJohannes Berg2010-08-161-2/+15
| | | | | | | | | 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 <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: unify scan and work mutexesJohannes Berg2010-08-161-4/+4
| | | | | | | | | | | | | 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 <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: allow drivers to request DTIM periodJohannes Berg2010-07-291-3/+29
| | | | | | | | | | | Some features require knowing the DTIM period before associating. This implements the ability to wait for a beacon in mac80211 before assoc to provide this value. It is optional since most likely not all drivers will need this. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: refuse shared key auth when WEP is unavailableJohannes Berg2010-07-211-0/+2
| | | | | | | | When WEP is not available, we should reject shared key authentication because it could never succeed. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: move QoS-enable to BSS infoJohannes Berg2010-07-201-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ever since commit e1b3ec1a2a336c328c336cfa5485a5f0484cc90d Author: Stanislaw Gruszka <sgruszka@redhat.com> Date: Mon Mar 29 12:18:34 2010 +0200 mac80211: explicitly disable/enable QoS mac80211 is telling drivers, in particular iwlwifi, whether QoS is enabled or not. However, this is only relevant for station mode, since only then will any device send nullfunc frames and need to know whether they should be QoS frames or not. In other modes, there are (currently) no frames the device is supposed to send. When you now consider virtual interfaces, it becomes apparent that the current mechanism is inadequate since it enables/disables QoS on a global scale, where for nullfunc frames it has to be on a per-interface scale. Due to the above considerations, we can change the way mac80211 advertises the QoS state to drivers to only ever advertise it as "off" in station mode, and make it a per-BSS setting. Tested-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: Add interface for driver to temporarily disable dynamic psJuuso Oikarinen2010-06-211-1/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This mechanism introduced in this patch applies (at least) for hardware designs using a single shared antenna for both WLAN and BT. In these designs, the antenna must be toggled between WLAN and BT. In those hardware, managing WLAN co-existence with Bluetooth requires WLAN full power save whenever there is Bluetooth activity in order for WLAN to be able to periodically relinquish the antenna to be used for BT. This is because BT can only access the shared antenna when WLAN is idle or asleep. Some hardware, for instance the wl1271, are able to indicate to the host whenever there is BT traffic. In essence, the hardware will send an indication to the host whenever there is, for example, SCO traffic or A2DP traffic, and will send another indication when the traffic is over. The hardware gets information of Bluetooth traffic via hardware co-existence control lines - these lines are used to negotiate the shared antenna ownership. The hardware will give the antenna to BT whenever WLAN is sleeping. This patch adds the interface to mac80211 to facilitate temporarily disabling of dynamic power save as per request of the WLAN driver. This interface will immediately force WLAN to full powersave, hence allowing BT coexistence as described above. In these kind of shared antenna desings, when WLAN powersave is fully disabled, Bluetooth will not work simultaneously with WLAN at all. This patch does not address that problem. This interface will not change PSM state, so if PSM is disabled it will remain so. Solving this problem requires knowledge about BT state, and is best done in user-space. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Merge branch 'master' of ↵John W. Linville2010-06-171-1/+38
|\ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 Conflicts: net/mac80211/mlme.c
| * mac80211: fix deauth before assocJohannes Berg2010-06-081-2/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we receive a deauthentication frame before having successfully associated, we neither print a message nor abort assocation. The former makes it hard to debug, while the latter later causes a warning in cfg80211 when, as will typically be the case, association timed out. This warning was reported by many, e.g. in https://bugzilla.kernel.org/show_bug.cgi?id=15981, but I couldn't initially pinpoint it. I verified the fix by hacking hostapd to send a deauth frame instead of an association response. Cc: stable@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Tested-by: Miles Lane <miles.lane@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: Protect Deauthentication frame when using MFPJouni Malinen2010-06-151-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | When management frame protection (IEEE 802.11w) is used, Deauthentication frame needs to be protected when the pairwise key is configured. mac80211 was removing the station entry (and its keys) before actually sending out the Deauthentication frame. Fix this by reordering the code to send the frame before the station entry gets removed. This matches an earlier change that handled the Disassociation frame processing, but missed Deauthentication frames. Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: Fix ps-qos network latency handlingJuuso Oikarinen2010-06-151-10/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ps-qos latency handling is broken. It uses predetermined latency values to select specific dynamic PS timeouts. With common AP configurations, these values overlap with beacon interval and are therefore essentially useless (for network latencies less than the beacon interval, PSM is disabled.) This patch remedies the problem by replacing the predetermined network latency values with one high value (1900ms) which is used to go trigger full psm. For backwards compatibility, the value 2000ms is still mapped to a dynamic ps timeout of 100ms. Currently also the mac80211 internal value for storing user space configured dynamic PSM values is incorrectly in the driver visible ieee80211_conf struct. Move it to the ieee80211_local struct. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: Fix circular locking dependency in ARP filter handlingJuuso Oikarinen2010-06-141-15/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a circular locking dependency when configuring the hardware ARP filters on association, occurring when flushing the mac80211 workqueue. This is what happens: [ 92.026800] ======================================================= [ 92.030507] [ INFO: possible circular locking dependency detected ] [ 92.030507] 2.6.34-04781-g2b2c009 #85 [ 92.030507] ------------------------------------------------------- [ 92.030507] modprobe/5225 is trying to acquire lock: [ 92.030507] ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<ffffffff8105b5c0>] flush_workq ueue+0x0/0xb0 [ 92.030507] [ 92.030507] but task is already holding lock: [ 92.030507] (rtnl_mutex){+.+.+.}, at: [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20 [ 92.030507] [ 92.030507] which lock already depends on the new lock. [ 92.030507] [ 92.030507] [ 92.030507] the existing dependency chain (in reverse order) is: [ 92.030507] [ 92.030507] -> #2 (rtnl_mutex){+.+.+.}: [ 92.030507] [<ffffffff810761fb>] lock_acquire+0xdb/0x110 [ 92.030507] [<ffffffff81341754>] mutex_lock_nested+0x44/0x300 [ 92.030507] [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20 [ 92.030507] [<ffffffffa022d47c>] ieee80211_assoc_done+0x6c/0xe0 [mac80211] [ 92.030507] [<ffffffffa022f2ad>] ieee80211_work_work+0x31d/0x1280 [mac80211] [ 92.030507] -> #1 ((&local->work_work)){+.+.+.}: [ 92.030507] [<ffffffff810761fb>] lock_acquire+0xdb/0x110 [ 92.030507] [<ffffffff8105a51a>] worker_thread+0x22a/0x370 [ 92.030507] [<ffffffff8105ecc6>] kthread+0x96/0xb0 [ 92.030507] [<ffffffff81003a94>] kernel_thread_helper+0x4/0x10 [ 92.030507] [ 92.030507] -> #0 ((wiphy_name(local->hw.wiphy))){+.+.+.}: [ 92.030507] [<ffffffff81075fdc>] __lock_acquire+0x1c0c/0x1d50 [ 92.030507] [<ffffffff810761fb>] lock_acquire+0xdb/0x110 [ 92.030507] [<ffffffff8105b60e>] flush_workqueue+0x4e/0xb0 [ 92.030507] [<ffffffffa023ff7b>] ieee80211_stop_device+0x2b/0xb0 [mac80211] [ 92.030507] [<ffffffffa0231635>] ieee80211_stop+0x3e5/0x680 [mac80211] The locking in this case is quite complex. Fix the problem by rewriting the way the hardware ARP filter list is handled - i.e. make a copy of the address list to the bss_conf struct, and provide that list to the hardware driver when needed. The current patch will enable filtering also in promiscuous mode. This may need to be changed in the future. Reported-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: always process blockack action from workqueueJohannes Berg2010-06-141-38/+0
| | | | | | | | | | | | | | | | | | | | | | To prepare for making the ampdu_action callback sleep, make mac80211 always process blockack action frames from the skb queue. This gets rid of the current special case for managed mode interfaces as well. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: pull mgmt frame rx into rx handlerJohannes Berg2010-06-141-27/+0
| | | | | | | | | | | | | | | | | | | | | | | | Some code is duplicated between ibss, mesh and managed mode regarding the queueing of management frames. Since all modes now use a common skb queue and a common work function, we can pull the queueing code into the rx handler directly and remove the duplicated length checks etc. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
OpenPOWER on IntegriCloud