1. 26 Aug, 2011 1 commit
  2. 24 Aug, 2011 3 commits
  3. 12 Aug, 2011 3 commits
  4. 11 Aug, 2011 2 commits
  5. 10 Aug, 2011 2 commits
  6. 01 Aug, 2011 1 commit
  7. 20 Jul, 2011 1 commit
  8. 19 Jul, 2011 1 commit
  9. 15 Jul, 2011 3 commits
  10. 06 Jul, 2011 1 commit
    • Johannes Berg's avatar
      cfg80211/nl80211: support GTK rekey offload · e5497d76
      Johannes Berg authored
      
      
      In certain circumstances, like WoWLAN scenarios,
      devices may implement (partial) GTK rekeying on
      the device to avoid waking up the host for it.
      
      In order to successfully go through GTK rekeying,
      the KEK, KCK and the replay counter are required.
      
      Add API to let the supplicant hand the parameters
      to the driver which may store it for future GTK
      rekey operations.
      
      Note that, of course, if GTK rekeying is done by
      the device, the EAP frame must not be passed up
      to userspace, instead a rekey event needs to be
      sent to let userspace update its replay counter.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e5497d76
  11. 05 Jul, 2011 1 commit
    • Luciano Coelho's avatar
      cfg80211: fix deadlock with rfkill/sched_scan by adding new mutex · c10841ca
      Luciano Coelho authored
      There was a deadlock when rfkill-blocking a wireless interface,
      because we were locking the rdev mutex on NETDEV_GOING_DOWN to stop
      sched_scans that were eventually running.  The rfkill block code was
      already holding a mutex under rdev:
      
      kernel: =======================================================
      kernel: [ INFO: possible circular locking dependency detected ]
      kernel: 3.0.0-rc1-00049-g1fa7b6a2
      
       #57
      kernel: -------------------------------------------------------
      kernel: kworker/0:1/4525 is trying to acquire lock:
      kernel: (&rdev->mtx){+.+.+.}, at: [<ffffffff8164c831>] cfg80211_netdev_notifier_call+0x131/0x5b0
      kernel:
      kernel: but task is already holding lock:
      kernel: (&rdev->devlist_mtx){+.+.+.}, at: [<ffffffff8164dcef>] cfg80211_rfkill_set_block+0x4f/0xa0
      kernel:
      kernel: which lock already depends on the new lock.
      
      To fix this, add a new mutex specifically for sched_scan, to protect
      the sched_scan_req element in the rdev struct, instead of using the
      global rdev mutex.
      Reported-by: default avatarDuane Griffin <duaneg@dghda.com>
      Signed-off-by: default avatarLuciano Coelho <coelho@ti.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      c10841ca
  12. 27 Jun, 2011 1 commit
  13. 22 Jun, 2011 1 commit
  14. 07 Jun, 2011 1 commit
  15. 01 Jun, 2011 2 commits
  16. 26 May, 2011 1 commit
  17. 19 May, 2011 1 commit
  18. 16 May, 2011 2 commits
    • Javier Cardona's avatar
      nl80211: Move peer link state definition to nl80211 · 57cf8043
      Javier Cardona authored
      
      
      These definitions need to be exposed now that we can set the peer link
      states via NL80211_ATTR_STA_PLINK_STATE.  They were already being
      (opaquely) reported by NL80211_STA_INFO_PLINK_STATE.
      Signed-off-by: default avatarJavier Cardona <javier@cozybit.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      57cf8043
    • Johannes Berg's avatar
      cfg80211: advertise possible interface combinations · 7527a782
      Johannes Berg authored
      
      
      Add the ability to advertise interface combinations in nl80211.
      This allows the driver to indicate what the combinations are
      that it supports. "Combinations" of just a single interface are
      implicit, as previously. Note that cfg80211 will enforce that
      the restrictions are met, but not for all drivers yet (once all
      drivers are updated, we can remove the flag and enforce for all).
      
      When no combinations are actually supported, an empty list will
      be exported so that userspace can know if the kernel exported
      this info or not (although it isn't clear to me what tools using
      the info should do if the kernel didn't export it).
      
      Since some interface types are purely virtual/software and don't
      fit the restrictions, those are exposed in a new list of pure SW
      types, not subject to restrictions. This mainly exists to handle
      AP-VLAN and monitor interfaces in mac80211.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      7527a782
  19. 12 May, 2011 1 commit
  20. 11 May, 2011 7 commits
  21. 05 May, 2011 2 commits
    • Johannes Berg's avatar
      nl80211/cfg80211: WoWLAN support · ff1b6e69
      Johannes Berg authored
      
      
      This is based on (but now quite far from) the
      original work from Luis and Eliad. Add support
      for configuring WoWLAN triggers, and getting
      the configuration out again. Changes from the
      original patchset are too numerous to list,
      but one important change needs highlighting:
      the suspend() callback is passed NULL for the
      trigger configuration if userspace has not
      configured WoWLAN at all.
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ff1b6e69
    • Jouni Malinen's avatar
      nl80211: Fix set_key regression with some drivers · 0e579d6a
      Jouni Malinen authored
      Commit dbd2fd65
      
       added a mechanism for
      user space to indicate whether a default key is being configured for
      only unicast or only multicast frames instead of all frames. This
      commit added a driver capability flag for indicating whether separate
      default keys are supported and validation of the set_key command based
      on that capability.
      
      However, this single capability flag is not enough to cover possible
      difference based on mode (AP/IBSS/STA) and the way this change was
      introduced resulted in a regression with drivers that do not indicate
      the new capability (i.e.., more or less any non-mac80211 driver using
      cfg80211) when using a recent wpa_supplicant snapshot.
      
      Fix the regression by removing the new check which is not strictly
      speaking needed. The new separate default key functionality is needed
      only for RSN IBSS which has a separate capability indication.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0e579d6a
  22. 12 Apr, 2011 2 commits