1. 05 2月, 2014 2 次提交
    • A
      cfg80211: fix channel configuration in IBSS join · fe94f3a4
      Antonio Quartulli 提交于
      When receiving an IBSS_JOINED event select the BSS object
      based on the {bssid, channel} couple rather than the bssid
      only.
      With the current approach if another cell having the same
      BSSID (but using a different channel) exists then cfg80211
      picks up the wrong BSS object.
      The result is a mismatching channel configuration between
      cfg80211 and the driver, that can lead to any sort of
      problem.
      
      The issue can be triggered by having an IBSS sitting on
      given channel and then asking the driver to create a new
      cell using the same BSSID but with a different frequency.
      By passing the channel to cfg80211_get_bss() we can solve
      this ambiguity and retrieve/create the correct BSS object.
      All the users of cfg80211_ibss_joined() have been changed
      accordingly.
      
      Moreover WARN when cfg80211_ibss_joined() gets a NULL
      channel as argument and remove a bogus call of the same
      function in ath6kl (it does not make sense to call
      cfg80211_ibss_joined() with a zero BSSID on ibss-leave).
      
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: Arend van Spriel <arend@broadcom.com>
      Cc: Bing Zhao <bzhao@marvell.com>
      Cc: Jussi Kivilinna <jussi.kivilinna@iki.fi>
      Cc: libertas-dev@lists.infradead.org
      Acked-by: NKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
      [minor code cleanup in ath6kl]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      fe94f3a4
    • J
      nl80211: fix scheduled scan RSSI matchset attribute confusion · ea73cbce
      Johannes Berg 提交于
      The scheduled scan matchsets were intended to be a list of filters,
      with the found BSS having to pass at least one of them to be passed
      to the host. When the RSSI attribute was added, however, this was
      broken and currently wpa_supplicant adds that attribute in its own
      matchset; however, it doesn't intend that to mean that anything
      that passes the RSSI filter should be passed to the host, instead
      it wants it to mean that everything needs to also have higher RSSI.
      
      This is semantically problematic because we have a list of filters
      like [ SSID1, SSID2, SSID3, RSSI ] with no real indication which
      one should be OR'ed and which one AND'ed.
      
      To fix this, move the RSSI filter attribute into each matchset. As
      we need to stay backward compatible, treat a matchset with only the
      RSSI attribute as a "default RSSI filter" for all other matchsets,
      but only if there are other matchsets (an RSSI-only matchset by
      itself is still desirable.)
      
      To make driver implementation easier, keep a global min_rssi_thold
      for the entire request as well. The only affected driver is ath6kl.
      
      I found this when I looked into the code after Raja Mani submitted
      a patch fixing the n_match_sets calculation to disregard the RSSI,
      but that patch didn't address the semantic issue.
      Reported-by: NRaja Mani <rmani@qti.qualcomm.com>
      Acked-by: NLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ea73cbce
  2. 02 12月, 2013 2 次提交
  3. 11 6月, 2013 1 次提交
  4. 04 6月, 2013 1 次提交
  5. 06 3月, 2013 1 次提交
    • J
      cfg80211: comprehensively check station changes · 77ee7c89
      Johannes Berg 提交于
      The station change API isn't being checked properly before
      drivers are called, and as a result it is difficult to see
      what should be allowed and what not.
      
      In order to comprehensively check the API parameters parse
      everything first, and then have the driver call a function
      (cfg80211_check_station_change()) with the additionally
      information about the kind of station that is being changed;
      this allows the function to make better decisions than the
      old code could.
      
      While at it, also add a few checks, particularly in mesh
      and clarify the TDLS station lifetime in documentation.
      
      To be able to reduce a few checks, ignore any flag set bits
      when the mask isn't set, they shouldn't be applied then.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      77ee7c89
  6. 05 3月, 2013 3 次提交
  7. 12 2月, 2013 2 次提交
  8. 14 1月, 2013 1 次提交
  9. 28 11月, 2012 4 次提交
  10. 26 11月, 2012 3 次提交
    • J
      nl80211/cfg80211: support VHT channel configuration · 3d9d1d66
      Johannes Berg 提交于
      Change nl80211 to support specifying a VHT (or HT)
      using the control channel frequency (as before) and
      new attributes for the channel width and first and
      second center frequency. The old channel type is of
      course still supported for HT.
      
      Also change the cfg80211 channel definition struct
      to support these by adding the relevant fields to
      it (and removing the _type field.)
      
      This also adds new helper functions:
       - cfg80211_chandef_create to create a channel def
         struct given the control channel and channel type,
       - cfg80211_chandef_identical to check if two channel
         definitions are identical
       - cfg80211_chandef_compatible to check if the given
         channel definitions are compatible, and return the
         wider of the two
      
      This isn't entirely complete, but that doesn't matter
      until we have a driver using it. In particular, it's
      missing
       - regulatory checks on the usable bandwidth (if that
         even makes sense)
       - regulatory TX power (database can't deal with it)
       - a proper channel compatibility calculation for the
         new channel types
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3d9d1d66
    • 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
  11. 16 11月, 2012 2 次提交
  12. 30 10月, 2012 1 次提交
    • J
      cfg80211: allow per interface TX power setting · c8442118
      Johannes Berg 提交于
      The TX power setting is currently per wiphy (hardware
      device) but with multi-channel capabilities that doesn't
      make much sense any more.
      
      Allow drivers (and mac80211) to advertise support for
      per-interface TX power configuration. When the TX power
      is configured for the wiphy, the wdev will be NULL and
      the driver can still handle that, but when a wdev is
      given the TX power can be set only for that wdev now.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c8442118
  13. 24 10月, 2012 15 次提交
  14. 18 10月, 2012 2 次提交
    • A
      wireless: drivers: make use of WLAN_EID_VENDOR_SPECIFIC · 04b2312a
      Arend van Spriel 提交于
      The include file linux/ieee80211.h contains three definitions for
      the same thing in enum ieee80211_eid due to historic changes:
      
      /* Information Element IDs */
      enum ieee80211_eid {
          :
          WLAN_EID_WPA = 221,
          WLAN_EID_GENERIC = 221,
          WLAN_EID_VENDOR_SPECIFIC = 221,
          :
      };
      
      The standard refers to this as "vendor specific" element so the
      other two definitions are better not used. This patch changes the
      wireless drivers to use one definition, ie. WLAN_EID_VENDOR_SPECIFIC.
      
      Cc: Jouni Malinen <j@w1.fi>
      Cc: Dan Williams <dcbw@redhat.com>
      Cc: Larry Finger <Larry.Finger@lwfinger.net>
      Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> [ath6kl]
      Acked-by: Bing Zhao <bzhao@marvell.com> [mwifiex]
      Acked-by: Stanislav Yakovlev <stas.yakovlev@gmail.com> [ipw2x00]
      Signed-off-by: NArend van Spriel <arend@broadcom.com>
      [change libipw as well]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      04b2312a
    • J
      wireless: use OR operation to set wiphy features · b292219f
      Johannes Berg 提交于
      The next patch will introduce a flag that is set
      by default in cfg80211 so drivers and mac80211
      need to use |= to set features they have so that
      they don't clear the already-set feature.
      
      We could set the flag in wiphy_register() instead
      of wiphy_new() to avoid this patch, but then the
      drivers couldn't *unset* flags they don't want to
      use even though the implementation is generic.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b292219f