1. 08 Nov, 2011 1 commit
  2. 30 Sep, 2011 3 commits
  3. 27 Sep, 2011 2 commits
  4. 14 Sep, 2011 1 commit
  5. 13 Sep, 2011 1 commit
  6. 12 Aug, 2011 1 commit
  7. 10 Aug, 2011 1 commit
  8. 19 Jul, 2011 1 commit
  9. 18 Jul, 2011 1 commit
  10. 15 Jul, 2011 1 commit
  11. 13 Jul, 2011 1 commit
    • Johannes Berg's avatar
      mac80211: allow driver to disconnect after resume · 95acac61
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      95acac61
  12. 11 Jul, 2011 1 commit
  13. 27 Jun, 2011 1 commit
  14. 10 Jun, 2011 1 commit
  15. 05 May, 2011 1 commit
  16. 04 Apr, 2011 1 commit
  17. 18 Feb, 2011 1 commit
  18. 09 Feb, 2011 1 commit
    • Eliad Peller's avatar
      mac80211: add missing locking in ieee80211_reconfig · a7b545f7
      Eliad Peller authored
      When suspending an associated system, and then resuming,
      the station vif is being reconfigured without taking the
      sdata->u.mgd.mtx lock, which results in the following warning:
      
      WARNING: at net/mac80211/mlme.c:101 ieee80211_ap_probereq_get+0x58/0xb8 [mac80211]()
      Modules linked in: wl12xx_sdio wl12xx firmware_class crc7 mac80211 cfg80211 [last unloaded: crc7]
      Backtrace:
      [<c005432c>] (dump_backtrace+0x0/0x118) from [<c0376e28>] (dump_stack+0x20/0x24)
       r7:00000000 r6:bf12d6ec r5:bf154aac r4:00000065
      [<c0376e08>] (dump_stack+0x0/0x24) from [<c0079104>] (warn_slowpath_common+0x5c/0x74)
      [<c00790a8>] (warn_slowpath_common+0x0/0x74) from [<c0079148>] (warn_slowpath_null+0x2c/0x34)
       r9:000024ff r8:cd006460 r7:00000001 r6:00000000 r5:00000000
      r4:cf1394a0
      [<c007911c>] (warn_slowpath_null+0x0/0x34) from [<bf12d6ec>] (ieee80211_ap_probereq_get+0x58/0xb8 [mac80211])
      [<bf12d694>] (ieee80211_ap_probereq_get+0x0/0xb8 [mac80211]) from [<bf19cd04>] (wl1271_cmd_build_ap_probe_req+0x30/0xf8 [wl12xx])
       r4:cd007440
      [<bf19ccd4>] (wl1271_cmd_build_ap_probe_req+0x0/0xf8 [wl12xx]) from [<bf1995f4>] (wl1271_op_bss_info_changed+0x4c4/0x808 [wl12xx])
       r5:cd007440 r4:000003b4
      [<bf199130>] (wl1271_op_bss_info_changed+0x0/0x808 [wl12xx]) from [<bf122168>] (ieee80211_bss_info_change_notify+0x1a4/0x1f8 [mac80211])
      [<bf121fc4>] (ieee80211_bss_info_change_notify+0x0/0x1f8 [mac80211]) from [<bf141e80>] (ieee80211_reconfig+0x4d0/0x668 [mac80211])
       r8:cf0eeea4 r7:cd00671c r6:00000000 r5:cd006460 r4:cf1394a0
      [<bf1419b0>] (ieee80211_reconfig+0x0/0x668 [mac80211]) from [<bf137dd4>] (ieee80211_resume+0x60/0x70 [mac80211])
      [<bf137d74>] (ieee80211_resume+0x0/0x70 [mac80211]) from [<bf0eb930>] (wiphy_resume+0x6c/0x7c [cfg80211])
       r5:cd006248 r4:cd006110
      [<bf0eb8c4>] (wiphy_resume+0x0/0x7c [cfg80211]) from [<c0241024>] (legacy_resume+0x38/0x70)
       r7:00000000 r6:00000000 r5:cd006248 r4:cd0062fc
      [<c0240fec>] (legacy_resume+0x0/0x70) from [<c0241478>] (device_resume+0x168/0x1a0)
       r8:c04ca8d8 r7:cd00627c r6:00000010 r5:cd006248 r4:cd0062fc
      [<c0241310>] (device_resume+0x0/0x1a0) from [<c0241600>] (dpm_resume_end+0xf8/0x3bc)
       r7:00000000 r6:00000005 r5:cd006248 r4:cd0062fc
      [<c0241508>] (dpm_resume_end+0x0/0x3bc) from [<c00b2a24>] (suspend_devices_and_enter+0x1b0/0x204)
      [<c00b2874>] (suspend_devices_and_enter+0x0/0x204) from [<c00b2b68>] (enter_state+0xf0/0x148)
       r7:c037e978 r6:00000003 r5:c043d807 r4:00000000
      [<c00b2a78>] (enter_state+0x0/0x148) from [<c00b20a4>] (state_store+0xa4/0xcc)
       r7:c037e978 r6:00000003 r5:00000003 r4:c043d807
      [<c00b2000>] (state_store+0x0/0xcc) from [<c01fc90c>] (kobj_attr_store+0x20/0x24)
      [<c01fc8ec>] (kobj_attr_store+0x0/0x24) from [<c0157120>] (sysfs_write_file+0x11c/0x150)
      [<c0157004>] (sysfs_write_file+0x0/0x150) from [<c0100f84>] (vfs_write+0xc0/0x14c)
      [<c0100ec4>] (vfs_write+0x0/0x14c) from [<c01010e4>] (sys_write+0x4c/0x78)
       r8:40126000 r7:00000004 r6:cf1a7c80 r5:00000000 r4:00000000
      [<c0101098>] (sys_write+0x0/0x78) from [<c00500c0>] (ret_fast_syscall+0x0/0x30)
       r8:c00502c8 r7:00000004 r6:403525e8 r5:40126000 r4:00000004
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a7b545f7
  19. 22 Dec, 2010 2 commits
  20. 17 Nov, 2010 1 commit
    • Johannes Berg's avatar
      mac80211: fix powersaving clients races · 50a9432d
      Johannes Berg authored
      The code to handle powersaving stations has a race:
      when the powersave flag is lifted from a station,
      we could transmit a packet that is being processed
      for TX at the same time right away, even if there
      are other frames queued for it. This would cause
      frame reordering. To fix this, lift the flag only
      under the appropriate lock that blocks TX.
      
      Additionally, the code to allow drivers to block a
      station while frames for it are on the HW queue is
      never re-enabled the station, so traffic would get
      stuck indefinitely. Fix this by clearing the flag
      for this appropriately.
      
      Finally, as an optimisation, don't do anything if
      the driver unblocks an already unblocked station.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      50a9432d
  21. 16 Nov, 2010 2 commits
  22. 06 Oct, 2010 1 commit
  23. 05 Oct, 2010 1 commit
  24. 24 Sep, 2010 2 commits
  25. 16 Sep, 2010 2 commits
  26. 27 Aug, 2010 3 commits
  27. 24 Aug, 2010 1 commit
  28. 26 Jul, 2010 1 commit
  29. 20 Jul, 2010 1 commit
    • Johannes Berg's avatar
      mac80211: move QoS-enable to BSS info · 4ced3f74
      Johannes Berg authored
      Ever since
      
      commit e1b3ec1a
      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: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4ced3f74
  30. 14 Jun, 2010 1 commit
    • Johannes Berg's avatar
      mac80211: simplify station/aggregation code · 2a419056
      Johannes Berg authored
      A number of places use RCU locking for accessing
      the station list, even though they do not need
      to. Use mutex locking instead to prepare for the
      locking changes I want to make. The mlme code is
      also using a WLAN_STA_DISASSOC flag that has the
      same meaning as WLAN_STA_BLOCK_BA, so use that.
      
      While doing so, combine places where we loop
      over stations twice, and optimise away some of
      the loops by checking if the hardware supports
      aggregation at all first.
      
      Also fix a more theoretical race condition: right
      now we could resume, set up an aggregation session,
      and right after tear it down again due to the code
      that is needed for hardware reconfiguration here.
      Also mark add a comment to that code marking it as
      a workaround.
      
      Finally, remove a pointless aggregation disabling
      loop when an interface is stopped, directly after
      that we remove all stations from it which will also
      disable all aggregation sessions that may still be
      active, and does so in a race-free way unlike the
      current loop that doesn't block new sessions.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2a419056
  31. 07 May, 2010 1 commit