1. 21 12月, 2010 2 次提交
  2. 17 12月, 2010 2 次提交
    • L
      cfg80211: fix null pointer dereference with a custom regulatory request · 2784fe91
      Luis R. Rodriguez 提交于
      Once we moved the core regulatory request to the queue and let
      the scheduler process it last_request will have been left NULL
      until the schedular decides to process the first request. When
      this happens and we are loading a driver with a custom regulatory
      request like all Atheros drivers we end up with a NULL pointer
      dereference. We fix this by checking if the request was a
      custom one.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
      IP: [<ffffffffa016de87>] freq_reg_info_regd.clone.2+0x27/0x130 [cfg80211]
      PGD 71f91067 PUD 712b2067 PMD 0
      Oops: 0000 [#1] PREEMPT SMP
      last sysfs file: /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/firmware/2-1/loading
      CPU 0
      Modules linked in: ath9k_htc(+) ath9k_common ath9k_hw ath <etc>
      Pid: 3094, comm: insmod Tainted: G        W   2.6.37-rc5-wl #16 INVALID/28427ZQ
      RIP: 0010:[<ffffffffa016de87>]  [<ffffffffa016de87>] freq_reg_info_regd.clone.2+0x27/0x130 [cfg80211]
      RSP: 0018:ffff88007045db78  EFLAGS: 00010282
      RAX: 0000000000000000 RBX: ffffffffa047d9a0 RCX: ffff88007045dbd0
      RDX: 0000000000004e20 RSI: 000000000024cde0 RDI: ffff8800700483e0
      RBP: ffff88007045db98 R08: ffffffffa02f5b40 R09: 0000000000000001
      R10: 000000000000000e R11: 0000000000000001 R12: 0000000000000000
      R13: ffff88007004e3b0 R14: 0000000000000000 R15: ffff880070048340
      FS:  00007f635a707700(0000) GS:ffff880077400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000004 CR3: 00000000708a9000 CR4: 00000000000006f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process insmod (pid: 3094, threadinfo ffff88007045c000, task ffff8800713e3ec0)
      Stack:
       ffffffffa047d9a0 0000000000000000 ffff88007004e3b0 0000000000000000
       ffff88007045dc08 ffffffffa016e147 000000007045dc08 0000000000000002
       ffff8800700483e0 ffffffffa02f5b40 ffff88007045dbd8 0000000000000000
      Call Trace:
       [<ffffffffa016e147>] wiphy_apply_custom_regulatory+0x137/0x1d0 [cfg80211]
       [<ffffffffa047a690>] ? ath9k_reg_notifier+0x0/0x50 [ath9k_htc]
       [<ffffffffa02f47f7>] ath_regd_init+0x347/0x430 [ath]
       [<ffffffffa047b1f5>] ath9k_htc_probe_device+0x6c5/0x960 [ath9k_htc]
       [<ffffffffa0472a2c>] ath9k_htc_hw_init+0xc/0x30 [ath9k_htc]
       [<ffffffffa04747e6>] ath9k_hif_usb_probe+0x216/0x3b0 [ath9k_htc]
       [<ffffffffa03bb6bc>] usb_probe_interface+0x10c/0x210 [usbcore]
       [<ffffffff812aec26>] driver_probe_device+0x96/0x1c0
       [<ffffffff812aedf3>] __driver_attach+0xa3/0xb0
       [<ffffffff812aed50>] ? __driver_attach+0x0/0xb0
       [<ffffffff812adaae>] bus_for_each_dev+0x5e/0x90
       [<ffffffff812ae8c9>] driver_attach+0x19/0x20
       [<ffffffff812ae438>] bus_add_driver+0x168/0x320
       [<ffffffff812af071>] driver_register+0x71/0x140
       [<ffffffff811fc4a8>] ? __raw_spin_lock_init+0x38/0x70
       [<ffffffffa03ba39c>] usb_register_driver+0xdc/0x190 [usbcore]
       [<ffffffffa03a2000>] ? ath9k_htc_init+0x0/0x4f [ath9k_htc]
       [<ffffffffa047499e>] ath9k_hif_usb_init+0x1e/0x20 [ath9k_htc]
       [<ffffffffa03a202b>] ath9k_htc_init+0x2b/0x4f [ath9k_htc]
       [<ffffffff8100212f>] do_one_initcall+0x3f/0x180
       [<ffffffff8109ef5b>] sys_init_module+0xbb/0x200
       [<ffffffff8100bf52>] system_call_fastpath+0x16/0x1b
      Code: <etc, who cares>
      RIP  [<ffffffffa016de87>] freq_reg_info_regd.clone.2+0x27/0x130 [cfg80211]
       RSP <ffff88007045db78>
      CR2: 0000000000000004
      ---[ end trace 79e4193601c8b713 ]---
      Reported-by: NSujith Manoharan <Sujith.Manoharan@atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2784fe91
    • J
      nl80211: Add notification for dropped Deauth/Disassoc · cf4e594e
      Jouni Malinen 提交于
      Add a new notification to indicate that a received, unprotected
      Deauthentication or Disassociation frame was dropped due to
      management frame protection being in use. This notification is
      needed to allow user space (e.g., wpa_supplicant) to implement
      SA Query procedure to recover from association state mismatch
      between an AP and STA.
      
      This is needed to avoid getting stuck in non-working state when MFP
      (IEEE 802.11w) is used and a protected Deauthentication or
      Disassociation frame is dropped for any reason. After that, the
      station would silently discard any unprotected Deauthentication or
      Disassociation frame that could be indicating that the AP does not
      have association for the STA (when the Reason Code would be 6 or 7).
      IEEE Std 802.11w-2009, 11.13 describes this recovery mechanism.
      Signed-off-by: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cf4e594e
  3. 16 12月, 2010 1 次提交
  4. 14 12月, 2010 2 次提交
    • J
      cfg80211/nl80211: separate unicast/multicast default TX keys · dbd2fd65
      Johannes Berg 提交于
      Allow userspace to specify that a given key
      is default only for unicast and/or multicast
      transmissions. Only WEP keys are for both,
      WPA/RSN keys set here are GTKs for multicast
      only. For more future flexibility, allow to
      specify all combiations.
      
      Wireless extensions can only set both so use
      nl80211; WEP keys (connect keys) must be set
      as default for both (but 802.1X WEP is still
      possible).
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      dbd2fd65
    • B
      cfg80211: Add antenna availability information · a7ffac95
      Bruno Randolf 提交于
      Add a field to wiphy for the hardware to report the availble antennas for
      configuration. Only if this is set to something bigger than zero, will the
      anntenna configuration ops be executed.
      
      Allthough this could be a simple number of antennas, I defined it as a bitmap
      of antennas which are available for configuration, since it's more consistent
      with the rest of the antenna API and there could be cases where the
      hardware allows only configuration of certain antennas. As it does not make
      much of a difference in size or normal usage, I think it's better to be able to
      support this, in case the need arises.
      
      The antenna configuration is now also checked against the availabe antennas and
      rejected if it does not match.
      Signed-off-by: NBruno Randolf <br1@einfach.org>
      
      --
      v3:	always apply available antenna mask (for "all" antennas case).
      
      v2:	reject antenna configurations which don't match the available antennas
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a7ffac95
  5. 09 12月, 2010 1 次提交
  6. 08 12月, 2010 1 次提交
  7. 07 12月, 2010 3 次提交
  8. 03 12月, 2010 1 次提交
  9. 30 11月, 2010 1 次提交
  10. 25 11月, 2010 3 次提交
  11. 19 11月, 2010 1 次提交
  12. 17 11月, 2010 2 次提交
    • F
    • B
      cfg80211: Add nl80211 antenna configuration · afe0cbf8
      Bruno Randolf 提交于
      Allow setting of TX and RX antennas configuration via nl80211.
      
      The antenna configuration is defined as a bitmap of allowed antennas to use.
      This API can be used to mask out antennas which are not attached or should not
      be used for other reasons like regulatory concerns or special setups.
      
      Separate bitmaps are used for RX and TX to allow configuring different antennas
      for receiving and transmitting. Each bitmap is 32 bit long, each bit
      representing one antenna, starting with antenna 1 at the first bit. If an
      antenna bit is set, this means the driver is allowed to use this antenna for RX
      or TX respectively; if the bit is not set the hardware is not allowed to use
      this antenna.
      
      Using bitmaps has the benefit of allowing for a flexible configuration
      interface which can support many different configurations and which can be used
      for 802.11n as well as non-802.11n devices. Instead of relying on some hardware
      specific assumptions, drivers can use this information to know which antennas
      are actually attached to the system and derive their capabilities based on
      that.
      
      802.11n devices should enable or disable chains, based on which antennas are
      present (If all antennas belonging to a particular chain are disabled, the
      entire chain should be disabled). HT capabilities (like STBC, TX Beamforming,
      Antenna selection) should be calculated based on the available chains after
      applying the antenna masks. Should a 802.11n device have diversity antennas
      attached to one of their chains, diversity can be enabled or disabled based on
      the antenna information.
      
      Non-802.11n drivers can use the antenna masks to select RX and TX antennas and
      to enable or disable antenna diversity.
      
      While covering chainmasks for 802.11n and the standard "legacy" modes "fixed
      antenna 1", "fixed antenna 2" and "diversity" this API also allows more rare,
      but useful configurations as follows:
      
      1) Send on antenna 1, receive on antenna 2 (or vice versa). This can be used to
      have a low gain antenna for TX in order to keep within the regulatory
      constraints and a high gain antenna for RX in order to receive weaker signals
      ("speak softly, but listen harder"). This can be useful for building long-shot
      outdoor links. Another usage of this setup is having a low-noise pre-amplifier
      on antenna 1 and a power amplifier on the other antenna. This way transmit
      noise is mostly kept out of the low noise receive channel.
      (This would be bitmaps: tx 1 rx 2).
      
      2) Another similar setup is: Use RX diversity on both antennas, but always send
      on antenna 1. Again that would allow us to benefit from a higher gain RX
      antenna, while staying within the legal limits.
      (This would be: tx 0 rx 3).
      
      3) And finally there can be special experimental setups in research and
      development even with pre 802.11n hardware where more than 2 antennas are
      available. It's good to keep the API simple, yet flexible.
      Signed-off-by: NBruno Randolf <br1@einfach.org>
      
      --
      v7:	Made bitmasks 32 bit wide and rebased to latest wireless-testing.
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      afe0cbf8
  13. 16 11月, 2010 2 次提交
  14. 14 10月, 2010 1 次提交
  15. 12 10月, 2010 2 次提交
  16. 08 10月, 2010 1 次提交
  17. 07 10月, 2010 2 次提交
  18. 06 10月, 2010 2 次提交
  19. 17 9月, 2010 1 次提交
  20. 28 8月, 2010 1 次提交
  21. 25 8月, 2010 3 次提交
  22. 30 7月, 2010 1 次提交
  23. 28 7月, 2010 2 次提交
  24. 21 7月, 2010 1 次提交
  25. 25 6月, 2010 1 次提交