1. 13 4月, 2017 2 次提交
  2. 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
  3. 06 3月, 2017 1 次提交
  4. 09 2月, 2017 1 次提交
    • L
      cfg80211: fix NAN bands definition · 8585989d
      Luca Coelho 提交于
      The nl80211_nan_dual_band_conf enumeration doesn't make much sense.
      The default value is assigned to a bit, which makes it weird if the
      default bit and other bits are set at the same time.
      
      To improve this, get rid of NL80211_NAN_BAND_DEFAULT and add a wiphy
      configuration to let the drivers define which bands are supported.
      This is exposed to the userspace, which then can make a decision on
      which band(s) to use.  Additionally, rename all "dual_band" elements
      to "bands", to make things clearer.
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8585989d
  5. 13 12月, 2016 1 次提交
    • M
      mac80211: multicast to unicast conversion · ebceec86
      Michael Braun 提交于
      Add the ability for an AP (and associated VLANs) to perform
      multicast-to-unicast conversion for ARP, IPv4 and IPv6 frames
      (possibly within 802.1Q). If enabled, such frames are to be sent
      to each station separately, with the DA replaced by their own
      MAC address rather than the group address.
      
      Note that this may break certain expectations of the receiver,
      such as the ability to drop unicast IP packets received within
      multicast L2 frames, or the ability to not send ICMP destination
      unreachable messages for packets received in L2 multicast (which
      is required, but the receiver can't tell the difference if this
      new option is enabled.)
      
      This also doesn't implement the 802.11 DMS (directed multicast
      service).
      Signed-off-by: NMichael Braun <michael-dev@fami-braun.de>
      [use true/false, rename label to the correct "multicast",
       use __be16 for ethertype and network order for constants]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ebceec86
  6. 27 10月, 2016 1 次提交
  7. 12 10月, 2016 3 次提交
    • M
      mac80211: filter multicast data packets on AP / AP_VLAN · 72f15d53
      Michael Braun 提交于
      This patch adds filtering for multicast data packets on AP_VLAN
      interfaces that have no authorized station connected and changes
      filtering on AP interfaces to not count stations assigned to
      AP_VLAN interfaces.
      
      This saves airtime and avoids waking up other stations currently
      authorized in this BSS. When using WPA, the packets dropped could
      not be decrypted by any station.
      
      The behaviour when there are no AP_VLAN interfaces is left unchanged.
      
      When there are AP_VLAN interfaces, this patch
      1. adds filtering multicast data packets sent on AP_VLAN interfaces
         that have no authorized station connected.
         No filtering happens on 4addr AP_VLAN interfaces.
      2. makes filtering of multicast data packets sent on AP interfaces
         depend on the number of authorized stations in this bss not
         assigned to an AP_VLAN interface.
      
      Therefore, a new num_mcast_sta counter is added for AP_VLAN interfaces.
      The existing one for AP interfaces is altered to not track stations
      assigned to an AP_VLAN interface.
      
      The new counter is exposed in debugfs.
      Signed-off-by: NMichael Braun <michael-dev@fami-braun.de>
      [reformat commit message a bit, unline ieee80211_vif_{inc,dec}_num_mcast]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      72f15d53
    • M
      mac80211: remove unnecessary num_mcast_sta check · 5f9994bd
      Michael Braun 提交于
      Checking for num_mcast_sta in __ieee80211_request_smps_ap() is
      unnecessary as sta list will be empty in this case anyway, so
      the list iteration will just exit immediately. Since this isn't
      a "hot" code path, it doesn't really matter, and the next patch
      will redefine num_mcast_sta to make this check invalid.
      Signed-off-by: NMichael Braun <michael-dev@fami-braun.de>
      [change commit message]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      5f9994bd
    • J
      mac80211: remove unnecessary mesh check · 850092db
      Johannes Berg 提交于
      sta_info_get_bss() is equivalent to sta_info_get() in the
      mesh case, since sta->sdata->bss will be NULL (it's only
      set for AP/AP_VLAN interfaces.) Thus, the mesh check here
      isn't actually needed - remove it.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      850092db
  8. 30 9月, 2016 5 次提交
  9. 15 9月, 2016 1 次提交
  10. 12 9月, 2016 2 次提交
  11. 05 8月, 2016 1 次提交
  12. 06 7月, 2016 1 次提交
  13. 12 4月, 2016 1 次提交
  14. 06 4月, 2016 2 次提交
    • J
      mac80211: add fast-rx path · 49ddf8e6
      Johannes Berg 提交于
      The regular RX path has a lot of code, but with a few
      assumptions on the hardware it's possible to reduce the
      amount of code significantly. Currently the assumptions
      on the driver are the following:
       * hardware/driver reordering buffer (if supporting aggregation)
       * hardware/driver decryption & PN checking (if using encryption)
       * hardware/driver did de-duplication
       * hardware/driver did A-MSDU deaggregation
       * AP_LINK_PS is used (in AP mode)
       * no client powersave handling in mac80211 (in client mode)
      
      of which some are actually checked per packet:
       * de-duplication
       * PN checking
       * decryption
      and additionally packets must
       * not be A-MSDU (have been deaggregated by driver/device)
       * be data packets
       * not be fragmented
       * be unicast
       * have RFC 1042 header
      
      Additionally dynamically we assume:
       * no encryption or CCMP/GCMP, TKIP/WEP/other not allowed
       * station must be authorized
       * 4-addr format not enabled
      
      Some data needed for the RX path is cached in a new per-station
      "fast_rx" structure, so that we only need to look at this and
      the packet, no other memory when processing packets on the fast
      RX path.
      
      After doing the above per-packet checks, the data path collapses
      down to a pretty simple conversion function taking advantage of
      the data cached in the small fast_rx struct.
      
      This should speed up the RX processing, and will make it easier
      to reason about parallelizing RX (for which statistics will need
      to be per-CPU still.)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      49ddf8e6
    • A
      mac80211: track and tell driver about GO client P2P PS abilities · 52cfa1d6
      Ayala Beker 提交于
      Legacy clients don't support P2P power save mechanism, and thus if a P2P GO
      has a legacy client connected to it, it should disable P2P PS mechanisms.
      Let the driver know about this with a new bss_conf parameter.
      Signed-off-by: NAyala Beker <ayala.beker@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      52cfa1d6
  15. 05 4月, 2016 1 次提交
    • B
      mac80211: mesh: move path tables into if_mesh · 2bdaf386
      Bob Copeland 提交于
      The mesh path and mesh gate hashtables are global, containing
      all of the mpaths for every mesh interface, but the paths are
      all tied logically to a single interface.  The common case is
      just a single mesh interface, so optimize for that by moving
      the global hashtable into the per-interface struct.
      
      Doing so allows us to drop sdata pointer comparisons inside
      the lookups and also saves a few bytes of BSS and data.
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      2bdaf386
  16. 24 2月, 2016 2 次提交
    • E
      mac80211: move TKIP TX IVs to public part of key struct · f8079d43
      Eliad Peller 提交于
      Some drivers/devices might want to set the IVs by
      themselves (and still let mac80211 generate MMIC).
      
      Specifically, this is needed when the device does
      offloading at certain times, and the driver has
      to make sure that the IVs of new tx frames (from
      the host) are synchronized with IVs that were
      potentially used during the offloading.
      
      Similarly to CCMP, move the TX IVs of TKIP keys to the
      public part of the key struct, and export a function
      to add the IV right into the crypto header.
      
      The public tx_pn field is defined as atomic64, so define
      TKIP_PN_TO_IV16/32 helper macros to convert it to iv16/32
      when needed.
      
      Since the iv32 used for the p1k cache is taken
      directly from the frame, we can safely remove
      iv16/32 from being protected by tkip.txlock.
      Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f8079d43
    • E
      mac80211: limit the A-MSDU Tx based on peer's capabilities · 506bcfa8
      Emmanuel Grumbach 提交于
      In VHT, the specification allows to limit the number of
      MSDUs in an A-MSDU in the Extended Capabilities IE. There
      is also a limitation on the byte size in the VHT IE.
      In HT, the only limitation is on the byte size.
      Parse the capabilities from the peer and make them
      available to the driver.
      
      In HT, there is another limitation when a BA agreement
      is active: the byte size can't be greater than 4095.
      This is not enforced here.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      506bcfa8
  17. 15 12月, 2015 1 次提交
  18. 04 12月, 2015 5 次提交
  19. 03 12月, 2015 1 次提交
    • J
      mac80211: fix off-channel mgmt-tx uninitialized variable usage · c1df932c
      Johannes Berg 提交于
      In the last change here, I neglected to update the cookie in one code
      path: when a mgmt-tx has no real cookie sent to userspace as it doesn't
      wait for a response, but is off-channel. The original code used the SKB
      pointer as the cookie and always assigned the cookie to the TX SKB in
      ieee80211_start_roc_work(), but my change turned this around and made
      the code rely on a valid cookie being passed in.
      
      Unfortunately, the off-channel no-wait TX path wasn't assigning one at
      all, resulting in an uninitialized stack value being used. This wasn't
      handed back to userspace as a cookie (since in the no-wait case there
      isn't a cookie), but it was tested for non-zero to distinguish between
      mgmt-tx and off-channel.
      
      Fix this by assigning a dummy non-zero cookie unconditionally, and get
      rid of a misleading comment and some dead code while at it. I'll clean
      up the ACK SKB handling separately later.
      
      Fixes: 3b79af97 ("mac80211: stop using pointers as userspace cookies")
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c1df932c
  20. 03 11月, 2015 1 次提交
  21. 15 10月, 2015 3 次提交
  22. 13 10月, 2015 1 次提交
  23. 29 9月, 2015 1 次提交
  24. 22 9月, 2015 1 次提交
    • S
      mac80211: reset CQM history upon reconfiguration · babc305e
      Sara Sharon 提交于
      The current behavior of notifying CQM events is inconsistent:
      Upon first configuration there is a cqm event with the current
      status according to threshold configured, regardless of signal
      stability.
      When there is reconfiguration no event is sent unless there is
      a significant change to the signal level according to the new
      configuration.
      
      Since the current reconfiguration behavior might cause missing
      CQM events in case the current signal did not change but is on
      the other side of the new threshold, fix that by resetting the
      stored signal level upon reconfiguration.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      babc305e