1. 27 Sep, 2011 2 commits
    • Jouni Malinen's avatar
      cfg80211: Validate cipher suite against supported ciphers · 38ba3c57
      Jouni Malinen authored
      
      
      Instead of using a hardcoded list of cipher suites in nl80211.c, use a
      shared function in util.c to verify that the driver advertises support
      for the specified cipher. This provides more accurate validation of the
      values and allows vendor-specific cipher suites to be added in drivers.
      Signed-off-by: default avatarJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      38ba3c57
    • Jouni Malinen's avatar
      cfg80211: Remove strict validation of AKM suites · 6d30240e
      Jouni Malinen authored
      
      
      NL80211_ATTR_AKM_SUITES can be used to configure new AKMs, like FT or
      the SHA-256 -based AKMs or FT from 802.11r/802.11w. In addition, vendor
      specific AKMs could be used. The current validation code for the connect
      command prevents cfg80211-based drivers from using these mechanisms even
      if the driver would not actually use this AKM value (i.e., it uses
      WPA/RSN IE from user space). mac80211-based drivers allow any AKM to be
      used since this value is not used there.
      
      Remove the unnecessary validation step in cfg80211 to allow drivers to
      decide what AKMs are supported. In theory, we could handle this by
      advertising supported AKMs, but that would not be very effective unless
      we enforce all drivers (including mac80211) to advertise the set of
      supported AKMs. This would require additional changes in many places
      whenever a new AKM is introduced even though no actually functionality
      changes may be required in most drivers.
      Signed-off-by: default avatarJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      6d30240e
  2. 19 Sep, 2011 2 commits
  3. 14 Sep, 2011 1 commit
  4. 13 Sep, 2011 3 commits
  5. 26 Aug, 2011 1 commit
  6. 24 Aug, 2011 3 commits
  7. 12 Aug, 2011 3 commits
  8. 11 Aug, 2011 2 commits
  9. 10 Aug, 2011 2 commits
  10. 01 Aug, 2011 1 commit
  11. 20 Jul, 2011 1 commit
  12. 19 Jul, 2011 1 commit
  13. 15 Jul, 2011 3 commits
  14. 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
  15. 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
  16. 27 Jun, 2011 1 commit
  17. 22 Jun, 2011 1 commit
  18. 07 Jun, 2011 1 commit
  19. 01 Jun, 2011 2 commits
  20. 26 May, 2011 1 commit
  21. 19 May, 2011 1 commit
  22. 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
  23. 12 May, 2011 1 commit
  24. 11 May, 2011 3 commits