1. 04 10月, 2011 1 次提交
  2. 01 10月, 2011 2 次提交
    • J
      mac80211: optimise station flags · c2c98fde
      Johannes Berg 提交于
      The flaglock in struct sta_info has long been
      something that I wanted to get rid of, this
      finally does the conversion to atomic bitops.
      
      The conversion itself is straight-forward in
      most places, a few things needed to change a
      bit since we can no longer use multiple bits
      at the same time.
      
      On x86-64, this is a fairly significant code
      size reduction:
         text	   data	    bss	    dec	    hex
       427861	  23648	   1008	 452517	  6e7a5	before
       425383	  23648	    976	 450007	  6ddd7	after
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c2c98fde
    • A
      nl80211/mac80211: allow adding TDLS peers as stations · 07ba55d7
      Arik Nemtsov 提交于
      When adding a TDLS peer STA, mark it with a new flag in both nl80211 and
      mac80211. Before adding a peer, make sure the wiphy supports TDLS and
      our operating mode is appropriate (managed).
      
      In addition, make sure all peers are removed on disassociation.
      
      A TDLS peer is first added just before link setup is initiated. In later
      setup stages we have more info about peer supported rates, capabilities,
      etc. This info is reported via nl80211_set_station().
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Cc: Kalyan C Gaddam <chakkal@iit.edu>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      07ba55d7
  3. 28 9月, 2011 2 次提交
  4. 20 9月, 2011 1 次提交
  5. 15 9月, 2011 2 次提交
  6. 14 9月, 2011 1 次提交
  7. 26 8月, 2011 1 次提交
    • G
      mac80211: fix race condition between assoc_done and first EAP packet · 2a33bee2
      Guy Eilam 提交于
      When associating to an AP, the station might miss the first EAP
      packet that the AP sends due to a race condition between the association
      success procedure and the rx flow in mac80211.
      In such cases, the packet might fall in ieee80211_rx_h_check due to
      the fact that the relevant rx->sta wasn't allocated yet.
      Allocation of the relevant station info struct before actually
      sending the association request and setting it with a new
      dummy_sta flag solve this problem.
      The station will accept only EAP packets from the AP while it
      is in the pre-association/dummy state.
      This dummy station entry is not seen by normal sta_info_get()
      calls, only by sta_info_get_bss_rx().
      The driver is not notified for the first insertion of the
      dummy station. The driver is notified only after the association
      is complete and the dummy flag is removed from the station entry.
      That way, all the rest of the code flow should be untouched by
      this change.
      Signed-off-by: NGuy Eilam <guy@wizery.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2a33bee2
  8. 21 7月, 2011 1 次提交
  9. 20 7月, 2011 1 次提交
  10. 19 7月, 2011 1 次提交
  11. 14 7月, 2011 1 次提交
    • J
      mac80211: allow driver to disconnect after resume · 95acac61
      Johannes Berg 提交于
      In WoWLAN, devices may use crypto keys for TX/RX
      and could also implement GTK rekeying. If the
      driver isn't able to retrieve replay counters and
      similar information from the device upon resume,
      or if the device isn't responsive due to platform
      issues, it isn't safe to keep the connection up
      as GTK rekey messages from during the sleep time
      could be replayed against it.
      
      The only protection against that is disconnecting
      from the AP. Modifying mac80211 to do that while
      it is resuming would be very complex and invasive
      in the case that the driver requires a reconfig,
      so do it after it has resumed completely. In that
      case, however, packets might be replayed since it
      can then only happen after TX/RX are up again, so
      mark keys for interfaces that need to disconnect
      as "tainted" and drop all packets that are sent
      or received with those keys.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      95acac61
  12. 12 7月, 2011 1 次提交
  13. 08 7月, 2011 1 次提交
  14. 06 7月, 2011 1 次提交
  15. 28 6月, 2011 2 次提交
  16. 18 6月, 2011 1 次提交
  17. 11 6月, 2011 1 次提交
  18. 08 6月, 2011 1 次提交
  19. 28 5月, 2011 1 次提交
  20. 27 5月, 2011 1 次提交
  21. 06 5月, 2011 2 次提交
  22. 13 4月, 2011 1 次提交
    • V
      mac80211: Check for queued frames before entering power save. · e8306f98
      Vivek Natarajan 提交于
      In a highly noisy environment, the tx rate of the driver drops and
      the application slows down since it has not yet received ACKs for
      the frames already queued in the hardware. Since this ACK may take
      more than 100ms, stopping the dev queues for entering PS at this
      stage breaks applications, WMM test cases in my testing.
      If there are frames already pending in the tx queue, postponing the
      PS logic helps to avoid redundant queue stops. When power save is
      enabled by default and in a noisy environment, this API certainly
      helps in improving the average throughput.
      Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e8306f98
  23. 08 4月, 2011 1 次提交
  24. 12 3月, 2011 1 次提交
  25. 26 2月, 2011 1 次提交
  26. 24 2月, 2011 1 次提交
    • V
      mac80211: Fix a race on enabling power save. · f3e85b9e
      Vivek Natarajan 提交于
      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: NVivek Natarajan <vnatarajan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f3e85b9e
  27. 19 2月, 2011 1 次提交
    • S
      mac80211: fix conn_mon_timer running after disassociate · 05e7c991
      Stanislaw Gruszka 提交于
      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: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      05e7c991
  28. 10 2月, 2011 1 次提交
  29. 08 2月, 2011 1 次提交
  30. 04 2月, 2011 1 次提交
  31. 01 2月, 2011 1 次提交
  32. 22 1月, 2011 1 次提交
    • B
      cfg80211: Extend channel to frequency mapping for 802.11j · 59eb21a6
      Bruno Randolf 提交于
      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: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NBrian Prodoehl <bprodoehl@gmail.com>
      Acked-by: NLuciano Coelho <coelho@ti.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      59eb21a6
  33. 20 1月, 2011 1 次提交
  34. 08 12月, 2010 2 次提交