1. 07 5月, 2018 1 次提交
  2. 19 4月, 2018 1 次提交
  3. 29 3月, 2018 4 次提交
  4. 21 3月, 2018 2 次提交
  5. 23 2月, 2018 2 次提交
  6. 11 12月, 2017 2 次提交
  7. 27 11月, 2017 1 次提交
  8. 20 11月, 2017 1 次提交
  9. 13 10月, 2017 1 次提交
    • J
      mac80211: don't track HT capability changes · b1b1ae2c
      Johannes Berg 提交于
      The code here (more or less accidentally) tracks the HT capability of
      the AP when connected, and we found at least one AP that erroneously
      toggles its 20/40 capability bit when changing between 20/40 MHz. The
      connection to the AP is then broken because we set the 40 MHz disable
      flag based on this, as soon as it switches to 20 MHz, but because the
      flag then changed, we disconnect.
      
      I'd be inclined to just ignore this issue, since we then reconnect
      while the AP is in 20 MHz mode and never use 40 MHz with it again,
      but this code is a bit strange anyway - we don't use the capabilities
      for anything else.
      
      Change the code to simply not track the HT capabilities at all, which
      assumes that the AP at least sets 20/40 capability when operating in
      40 MHz (or higher). If not, rate scaling might end up using only the
      narrower bandwidth.
      
      The new behaviour also mirrors what VHT does, where we only check the
      VHT operation.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b1b1ae2c
  10. 21 9月, 2017 1 次提交
    • J
      mac80211: simplify and clarify IE splitting · a7f26d80
      Johannes Berg 提交于
      There's no need to split off IEs from the ones obtained
      from userspace, if they were already split off, so for
      example IEs that went before HT don't have to be listed
      again to go before VHT. Simplify the code here so it's
      clearer.
      
      While at it, also clarify the comments regarding the DMG
      (60 GHz) elements.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      a7f26d80
  11. 05 9月, 2017 1 次提交
  12. 21 6月, 2017 1 次提交
  13. 16 6月, 2017 2 次提交
    • J
      networking: introduce and use skb_put_data() · 59ae1d12
      Johannes Berg 提交于
      A common pattern with skb_put() is to just want to memcpy()
      some data into the new space, introduce skb_put_data() for
      this.
      
      An spatch similar to the one for skb_put_zero() converts many
      of the places using it:
      
          @@
          identifier p, p2;
          expression len, skb, data;
          type t, t2;
          @@
          (
          -p = skb_put(skb, len);
          +p = skb_put_data(skb, data, len);
          |
          -p = (t)skb_put(skb, len);
          +p = skb_put_data(skb, data, len);
          )
          (
          p2 = (t2)p;
          -memcpy(p2, data, len);
          |
          -memcpy(p, data, len);
          )
      
          @@
          type t, t2;
          identifier p, p2;
          expression skb, data;
          @@
          t *p;
          ...
          (
          -p = skb_put(skb, sizeof(t));
          +p = skb_put_data(skb, data, sizeof(t));
          |
          -p = (t *)skb_put(skb, sizeof(t));
          +p = skb_put_data(skb, data, sizeof(t));
          )
          (
          p2 = (t2)p;
          -memcpy(p2, data, sizeof(*p));
          |
          -memcpy(p, data, sizeof(*p));
          )
      
          @@
          expression skb, len, data;
          @@
          -memcpy(skb_put(skb, len), data, len);
          +skb_put_data(skb, data, len);
      
      (again, manually post-processed to retain some comments)
      Reviewed-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59ae1d12
    • J
      networking: convert many more places to skb_put_zero() · b080db58
      Johannes Berg 提交于
      There were many places that my previous spatch didn't find,
      as pointed out by yuan linyu in various patches.
      
      The following spatch found many more and also removes the
      now unnecessary casts:
      
          @@
          identifier p, p2;
          expression len;
          expression skb;
          type t, t2;
          @@
          (
          -p = skb_put(skb, len);
          +p = skb_put_zero(skb, len);
          |
          -p = (t)skb_put(skb, len);
          +p = skb_put_zero(skb, len);
          )
          ... when != p
          (
          p2 = (t2)p;
          -memset(p2, 0, len);
          |
          -memset(p, 0, len);
          )
      
          @@
          type t, t2;
          identifier p, p2;
          expression skb;
          @@
          t *p;
          ...
          (
          -p = skb_put(skb, sizeof(t));
          +p = skb_put_zero(skb, sizeof(t));
          |
          -p = (t *)skb_put(skb, sizeof(t));
          +p = skb_put_zero(skb, sizeof(t));
          )
          ... when != p
          (
          p2 = (t2)p;
          -memset(p2, 0, sizeof(*p));
          |
          -memset(p, 0, sizeof(*p));
          )
      
          @@
          expression skb, len;
          @@
          -memset(skb_put(skb, len), 0, len);
          +skb_put_zero(skb, len);
      
      Apply it to the tree (with one manual fixup to keep the
      comment in vxlan.c, which spatch removed.)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b080db58
  14. 13 6月, 2017 2 次提交
  15. 19 5月, 2017 1 次提交
  16. 08 5月, 2017 1 次提交
  17. 28 4月, 2017 2 次提交
    • A
      mac80211: Add support for BSS max idle period element · e38a017b
      Avraham Stern 提交于
      Parse the BSS max idle period element and set the BSS configuration
      accordingly so the driver can use this information to configure the
      max idle period and to use protected management frames for keep alive
      when required.
      
      The BSS max idle period element is defined in IEEE802.11-2016,
      section 9.4.2.79
      Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e38a017b
    • M
      mac80211: Fix possible sband related NULL pointer de-reference · 21a8e9dd
      Mohammed Shafi Shajakhan 提交于
      Existing API 'ieee80211_get_sdata_band' returns default 2 GHz band even
      if the channel context configuration is NULL. This crashes for chipsets
      which support 5 Ghz alone when it tries to access members of 'sband'.
      Channel context configuration can be NULL in multivif case and when
      channel switch is in progress (or) when it fails. Fix this by replacing
      the API 'ieee80211_get_sdata_band' with  'ieee80211_get_sband' which
      returns a NULL pointer for sband when the channel configuration is NULL.
      
      An example scenario is as below:
      
      In multivif mode (AP + STA) with drivers like ath10k, when we do a
      channel switch in the AP vif (which has a number of clients connected)
      and a STA vif which is connected to some other AP, when the channel
      switch in AP vif fails, while the STA vifs tries to connect to the
      other AP, there is a window where the channel context is NULL/invalid
      and this results in a crash  while the clients connected to the AP vif
      tries to reconnect and this race is very similar to the one investigated
      by Michal in https://patchwork.kernel.org/patch/3788161/ and this does
      happens with hardware that supports 5Ghz alone after long hours of
      testing with continuous channel switch on the AP vif
      
      ieee80211 phy0: channel context reservation cannot be finalized because
      some interfaces aren't switching
      wlan0: failed to finalize CSA, disconnecting
      wlan0-1: deauthenticating from 8c:fd:f0:01:54:9c by local choice
      	(Reason: 3=DEAUTH_LEAVING)
      
      	WARNING: CPU: 1 PID: 19032 at net/mac80211/ieee80211_i.h:1013 sta_info_alloc+0x374/0x3fc [mac80211]
      	[<bf77272c>] (sta_info_alloc [mac80211])
      	[<bf78776c>] (ieee80211_add_station [mac80211]))
      	[<bf73cc50>] (nl80211_new_station [cfg80211])
      
      	Unable to handle kernel NULL pointer dereference at virtual
      	address 00000014
      	pgd = d5f4c000
      	Internal error: Oops: 17 [#1] PREEMPT SMP ARM
      	PC is at sta_info_alloc+0x380/0x3fc [mac80211]
      	LR is at sta_info_alloc+0x37c/0x3fc [mac80211]
      	[<bf772738>] (sta_info_alloc [mac80211])
      	[<bf78776c>] (ieee80211_add_station [mac80211])
      	[<bf73cc50>] (nl80211_new_station [cfg80211]))
      
      Cc: Michal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      21a8e9dd
  18. 08 3月, 2017 1 次提交
    • J
      mac80211: reject/clear user rate mask if not usable · e8e4f528
      Johannes Berg 提交于
      If the user rate mask results in no (basic) rates being usable,
      clear it. Also, if we're already operating when it's set, reject
      it instead.
      
      Technically, selecting basic rates as the criterion is a bit too
      restrictive, but calculating the usable rates over all stations
      (e.g. in AP mode) is harder, and all stations must support the
      basic rates. Similarly, in client mode, the basic rates will be
      used anyway for control frames.
      
      This fixes the "no supported rates (...) in rate_mask ..." warning
      that occurs on TX when you've selected a rate mask that's not
      compatible with the connection (e.g. an AP that enables only the
      rates 36, 48, 54 and you've selected only 6, 9, 12.)
      Reported-by: NKirtika Ruchandani <kirtika@google.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e8e4f528
  19. 07 3月, 2017 1 次提交
  20. 06 3月, 2017 2 次提交
  21. 08 2月, 2017 2 次提交
    • A
      cfg80211: Pass new RSSI level in CQM RSSI notification · bee427b8
      Andrzej Zaborowski 提交于
      Update the drivers to pass the RSSI level as a cfg80211_cqm_rssi_notify
      parameter and pass this value to userspace in a new nl80211 attribute.
      This helps both userspace and also helps in the implementation of the
      multiple RSSI thresholds CQM mechanism.
      
      Note for marvell/mwifiex I pass 0 for the RSSI value because the new
      RSSI value is not available to the driver at the time of the
      cfg80211_cqm_rssi_notify call, but the driver queries the new value
      immediately after that, so it is actually available just a moment later
      if we wanted to defer caling cfg80211_cqm_rssi_notify until that moment.
      Without this, the new cfg80211 code (patch 3) will call .get_station
      which will send a duplicate HostCmd_CMD_RSSI_INFO command to the hardware.
      Signed-off-by: NAndrew Zaborowski <andrew.zaborowski@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      bee427b8
    • A
      mac80211: Pass new RSSI level in CQM RSSI notification · 769f07d8
      Andrzej Zaborowski 提交于
      Extend ieee80211_cqm_rssi_notify with a rssi_level parameter so that
      this information can be passed to netlink clients in the next patch, if
      available.  Most drivers will have this value at hand.  wl1251 receives
      events from the firmware that only tell it whether latest measurement
      is above or below threshold so we don't pass any value at this time
      (parameter is 0).
      Signed-off-by: NAndrew Zaborowski <andrew.zaborowski@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      769f07d8
  22. 13 12月, 2016 1 次提交
  23. 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
  24. 27 10月, 2016 4 次提交
  25. 19 10月, 2016 1 次提交
  26. 15 9月, 2016 1 次提交
    • J
      mac80211: fix possible out-of-bounds access · 93db1d9e
      Johannes Berg 提交于
      In the unlikely situation that the supplicant has negotiated
      admission for the background AC (which it has no reason to as
      it's not supposed to be requiring admission control to start
      with, and we'd ignore such a requirement anyway), the loop
      here may terminate with non_acm_ac == 4, which leads to an
      array overrun.
      
      Check this explicitly just for completeness.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      93db1d9e