1. 09 1月, 2017 1 次提交
  2. 09 12月, 2016 1 次提交
    • J
      cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts · e6f462df
      Johannes Berg 提交于
      When mac80211 abandons an association attempt, it may free
      all the data structures, but inform cfg80211 and userspace
      about it only by sending the deauth frame it received, in
      which case cfg80211 has no link to the BSS struct that was
      used and will not cfg80211_unhold_bss() it.
      
      Fix this by providing a way to inform cfg80211 of this with
      the BSS entry passed, so that it can clean up properly, and
      use this ability in the appropriate places in mac80211.
      
      This isn't ideal: some code is more or less duplicated and
      tracing is missing. However, it's a fairly small change and
      it's thus easier to backport - cleanups can come later.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e6f462df
  3. 27 10月, 2016 1 次提交
    • J
      cfg80211: Rename SAE_DATA to more generic AUTH_DATA · 11b6b5a4
      Jouni Malinen 提交于
      This adds defines and nl80211 extensions to allow FILS Authentication to
      be implemented similarly to SAE. FILS does not need the special rules
      for the Authentication transaction number and Status code fields, but it
      does need to add non-IE fields. The previously used
      NL80211_ATTR_SAE_DATA can be reused for this to avoid having to
      duplicate that implementation. Rename that attribute to more generic
      NL80211_ATTR_AUTH_DATA (with backwards compatibility define for
      NL80211_SAE_DATA).
      
      Also document the special rules related to the Authentication
      transaction number and Status code fiels.
      Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      11b6b5a4
  4. 30 9月, 2016 1 次提交
  5. 14 9月, 2016 1 次提交
  6. 12 4月, 2016 1 次提交
  7. 14 1月, 2016 1 次提交
  8. 17 7月, 2015 1 次提交
    • J
      cfg80211: allow mgmt_frame_register callback to sleep · 33d8783c
      Johannes Berg 提交于
      This callback is currently not allowed to sleep, which makes it more
      difficult to implement proper driver methods in mac80211 than it has
      to be. Instead of doing asynchronous work here in mac80211, make it
      possible for the callback to sleep by doing some asynchronous work
      in cfg80211. This also enables improvements to other drivers, like
      ath6kl, that would like to sleep in this callback.
      
      While at it, also fix the code to call the driver on the implicit
      unregistration when an interface is removed, and do that also when
      a P2P-Device wdev is destroyed (otherwise we leak the structs.)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      33d8783c
  9. 03 3月, 2015 1 次提交
    • D
      cfg80211: add bss_type and privacy arguments in cfg80211_get_bss() · 6eb18137
      Dedy Lansky 提交于
      802.11ad adds new a network type (PBSS) and changes the capability
      field interpretation for the DMG (60G) band.
      The same 2 bits that were interpreted as "ESS" and "IBSS" before are
      re-used as a 2-bit field with 3 valid values (and 1 reserved). Valid
      values are: "IBSS", "PBSS" (new) and "AP".
      
      In order to get the BSS struct for the new PBSS networks, change the
      cfg80211_get_bss() function to take a new enum ieee80211_bss_type
      argument with the valid network types, as "capa_mask" and "capa_val"
      no longer work correctly (the search must be band-aware now.)
      
      The remaining bits in "capa_mask" and "capa_val" are used only for
      privacy matching so replace those two with a privacy enum as well.
      Signed-off-by: NDedy Lansky <dlansky@codeaurora.org>
      [rewrite commit log, tiny fixes]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6eb18137
  10. 11 9月, 2014 1 次提交
  11. 26 8月, 2014 1 次提交
  12. 25 4月, 2014 1 次提交
  13. 09 4月, 2014 1 次提交
  14. 26 2月, 2014 1 次提交
  15. 05 2月, 2014 1 次提交
    • M
      cfg80211: consider existing DFS interfaces · 9e0e2961
      Michal Kazior 提交于
      It was possible to break interface combinations in
      the following way:
      
       combo 1: iftype = AP, num_ifaces = 2, num_chans = 2,
       combo 2: iftype = AP, num_ifaces = 1, num_chans = 1, radar = HT20
      
      With the above interface combinations it was
      possible to:
      
       step 1. start AP on DFS channel by matching combo 2
       step 2. start AP on non-DFS channel by matching combo 1
      
      This was possible beacuse (step 2) did not consider
      if other interfaces require radar detection.
      
      The patch changes how cfg80211 tracks channels -
      instead of channel itself now a complete chandef
      is stored.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      9e0e2961
  16. 02 12月, 2013 1 次提交
  17. 26 11月, 2013 1 次提交
  18. 21 10月, 2013 2 次提交
  19. 23 8月, 2013 1 次提交
  20. 20 6月, 2013 2 次提交
  21. 04 6月, 2013 2 次提交
    • J
      cfg80211: separate internal SME implementation · ceca7b71
      Johannes Berg 提交于
      The current internal SME implementation in cfg80211 is
      very mixed up with the MLME handling, which has been
      causing issues for a long time. There are three things
      that the implementation has to provide:
       * a basic SME implementation for nl80211's connect()
         call (for drivers implementing auth/assoc, which is
         really just mac80211) and wireless extensions
       * MLME events for the userspace SME
       * SME events (connected, disconnected etc.) for all
         different SME implementation possibilities (driver,
         cfg80211 and userspace)
      
      To achieve these goals it isn't necessary to track the
      software SME's connection status outside of it's state
      (which is the part that caused many issues.) Instead,
      track it only in the SME data (wdev->conn) and in the
      general case only track whether the wdev is connected
      or not (via wdev->current_bss.)
      
      Also separate the internal implementation to not have
      callbacks from the SME events, but rather call it from
      the API functions that the driver (or rather mac80211)
      calls. This separates the code better.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ceca7b71
    • J
      cfg80211/mac80211: clean up cfg80211 SME APIs · 6ff57cf8
      Johannes Berg 提交于
      Do some cleanups in the cfg80211 SME APIs, which are
      only used by mac80211.
      
      Most of these functions get a frame passed, and there
      isn't really any reason to export multiple functions
      as cfg80211 can check the frame type instead, do that.
      
      Additionally, the API functions have confusing names
      like cfg80211_send_...() which was meant to indicate
      that it sends an event to userspace, but gets a bit
      confusing when there's both TX and RX and they're not
      all clearly labeled.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6ff57cf8
  22. 25 5月, 2013 3 次提交
    • J
      cfg80211: remove some locked wrappers from mlme API · 91bf9b26
      Johannes Berg 提交于
      By making all the API functions require wdev locking we
      can clean up the API a bit, getting rid of the locking
      version of each function. This also decreases the size
      of cfg80211 by a small amount.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      91bf9b26
    • J
      cfg80211/mac80211: use cfg80211 wdev mutex in mac80211 · 8d61ffa5
      Johannes Berg 提交于
      Using separate locks in cfg80211 and mac80211 has always
      caused issues, for example having to unlock in places in
      mac80211 to call cfg80211, which even needed a framework
      to make cfg80211 calls after some functions returned etc.
      
      Additionally, I suspect some issues people have reported
      with the cfg80211 state getting confused could be due to
      such issues, when cfg80211 is asking mac80211 to change
      state but mac80211 is in the process of telling cfg80211
      that the state changed (in another way.)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8d61ffa5
    • J
      cfg80211: vastly simplify locking · 5fe231e8
      Johannes Berg 提交于
      Virtually all code paths in cfg80211 already (need to) hold
      the RTNL. As such, there's little point in having another
      four mutexes for various parts of the code, they just cause
      lock ordering issues (and much of the time, the RTNL and a
      few of the others need thus be held.)
      
      Simplify all this by getting rid of the extra four mutexes
      and just use the RTNL throughout. Only a few code changes
      were needed to do this and we can get rid of a work struct
      for bonus points.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      5fe231e8
  23. 17 5月, 2013 1 次提交
  24. 22 4月, 2013 1 次提交
  25. 06 3月, 2013 3 次提交
  26. 15 2月, 2013 1 次提交
  27. 12 2月, 2013 1 次提交
  28. 29 1月, 2013 1 次提交
  29. 03 1月, 2013 1 次提交
  30. 26 11月, 2012 2 次提交
    • J
      cfg80211: pass a channel definition struct · 683b6d3b
      Johannes Berg 提交于
      Instead of passing a channel pointer and channel type
      to all functions and driver methods, pass a new channel
      definition struct. Right now, this struct contains just
      the control channel and channel type, but for VHT this
      will change.
      
      Also, add a small inline cfg80211_get_chandef_type() so
      that drivers don't need to use the _type field of the
      new structure all the time, which will change.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      683b6d3b
    • J
      cfg80211: remove remain-on-channel channel type · 42d97a59
      Johannes Berg 提交于
      As mwifiex (and mac80211 in the software case) are the
      only drivers actually implementing remain-on-channel
      with channel type, userspace can't be relying on it.
      This is the case, as it's used only for P2P operations
      right now.
      
      Rather than adding a flag to tell userspace whether or
      not it can actually rely on it, simplify all the code
      by removing the ability to use different channel types.
      Leave only the validation of the attribute, so that if
      we extend it again later (with the needed capability
      flag), it can't break userspace sending invalid data.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      42d97a59
  31. 18 10月, 2012 2 次提交