1. 16 7月, 2011 3 次提交
  2. 07 7月, 2011 1 次提交
    • J
      cfg80211/nl80211: support GTK rekey offload · e5497d76
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e5497d76
  3. 06 7月, 2011 1 次提交
    • L
      cfg80211: fix deadlock with rfkill/sched_scan by adding new mutex · c10841ca
      Luciano Coelho 提交于
      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: NDuane Griffin <duaneg@dghda.com>
      Signed-off-by: NLuciano Coelho <coelho@ti.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c10841ca
  4. 28 6月, 2011 1 次提交
  5. 23 6月, 2011 1 次提交
  6. 08 6月, 2011 1 次提交
  7. 02 6月, 2011 2 次提交
  8. 27 5月, 2011 1 次提交
  9. 20 5月, 2011 1 次提交
  10. 17 5月, 2011 2 次提交
    • J
      nl80211: Move peer link state definition to nl80211 · 57cf8043
      Javier Cardona 提交于
      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: NJavier Cardona <javier@cozybit.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      57cf8043
    • J
      cfg80211: advertise possible interface combinations · 7527a782
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7527a782
  11. 13 5月, 2011 1 次提交
  12. 12 5月, 2011 7 次提交
  13. 06 5月, 2011 2 次提交
    • J
      nl80211/cfg80211: WoWLAN support · ff1b6e69
      Johannes Berg 提交于
      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: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ff1b6e69
    • J
      nl80211: Fix set_key regression with some drivers · 0e579d6a
      Jouni Malinen 提交于
      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: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0e579d6a
  14. 13 4月, 2011 6 次提交
  15. 08 4月, 2011 1 次提交
  16. 31 3月, 2011 1 次提交
  17. 02 3月, 2011 1 次提交
  18. 29 1月, 2011 1 次提交
    • J
      net/wireless/nl80211.c: Avoid call to genlmsg_cancel · efe1cf0c
      Julia Lawall 提交于
      genlmsg_cancel subtracts some constants from its second argument before
      calling nlmsg_cancel.  nlmsg_cancel then calls nlmsg_trim on the same
      arguments.  nlmsg_trim tests for NULL before doing any computation, but a
      NULL second argument to genlmsg_cancel is no longer NULL due to the initial
      subtraction.  Nothing else happens in this execution, so the call to
      genlmsg_cancel is simply unnecessary in this case.
      
      The semantic match that finds this problem is as follows:
      (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @@
      expression data;
      @@
      
      if (data == NULL) { ...
      * genlmsg_cancel(..., data);
        ...
        return ...;
      }
      // </smpl>
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      efe1cf0c
  19. 21 12月, 2010 5 次提交
  20. 17 12月, 2010 1 次提交
    • 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