1. 28 2月, 2017 1 次提交
    • J
      mac80211: use driver-indicated transmitter STA only for data frames · 19d19e96
      Johannes Berg 提交于
      When I originally introduced using the driver-indicated station as an
      optimisation to avoid the hashtable lookup/iteration, of course it
      wasn't intended to really functionally change anything.
      
      I neglected, however, to take into account VLAN interfaces, which have
      the property that management and data frames are handled differently:
      data frames go directly to the station and the VLAN while management
      frames continue to be processed over the underlying/associated AP-type
      interface. As a consequence, when a driver used this optimisation for
      management frames and the user enabled VLANs, my change broke things
      since any management frames, particularly disassoc/deauth, were missed
      by hostapd.
      
      Fix this by restoring the original code path for non-data frames, they
      aren't critical for performance to begin with.
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=194713.
      
      Big thanks goes to Jarek who bisected the issue and provided a very
      detailed bug report, including the crucial information that he was
      using VLANs in his configuration.
      
      Cc: stable@vger.kernel.org
      Fixes: 771e846bea9e ("mac80211: allow passing transmitter station on RX")
      Reported-and-tested-by: NJarek Kamiński <jarek@freeside.be>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      19d19e96
  2. 27 2月, 2017 2 次提交
  3. 26 1月, 2017 1 次提交
  4. 11 1月, 2017 2 次提交
  5. 09 1月, 2017 1 次提交
    • J
      mac80211: implement multicast forwarding on fast-RX path · eeb0d56f
      Johannes Berg 提交于
      In AP (or VLAN) mode, when unicast 802.11 packets are received,
      they might actually be multicast after conversion. In this case
      the fast-RX path didn't handle them properly to send them back
      to the wireless medium. Implement that by copying the SKB and
      sending it back out.
      
      The possible alternative would be to just punt the packet back
      to the regular (slow) RX path, but since we have almost all of
      the required code here already it's not so complicated to add
      here. Punting it back would also mean acquiring the spinlock,
      which would be bad for the stated purpose of the fast-RX path,
      to enable well-performing parallel RX.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      eeb0d56f
  6. 13 12月, 2016 2 次提交
  7. 19 10月, 2016 2 次提交
  8. 12 10月, 2016 5 次提交
    • 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
    • J
      mac80211: validate DA/SA during A-MSDU decapsulation · e2b5227f
      Johannes Berg 提交于
      As pointed out by Michael Braun, we don't check inner L2 addresses
      during A-MSDU decapsulation, leading to the possibility that, for
      example, a station associated to an AP sends frames as though they
      came from somewhere else.
      
      Fix this problem by letting cfg80211 validate the addresses, as
      indicated by passing in the ones that need to be validated.
      Reported-by: NMichael Braun <michael-dev@fami-braun.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e2b5227f
    • J
      cfg80211: add ability to check DA/SA in A-MSDU decapsulation · 8b935ee2
      Johannes Berg 提交于
      We should not accept arbitrary DA/SA inside A-MSDUs, it could be used
      to circumvent protections, like allowing a station to send frames and
      make them seem to come from somewhere else.
      
      Add the necessary infrastructure in cfg80211 to allow such checks, in
      further patches we'll start using them.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8b935ee2
    • J
      cfg80211: let ieee80211_amsdu_to_8023s() take only header-less SKB · 7f6990c8
      Johannes Berg 提交于
      There's only a single case where has_80211_header is passed as true,
      which is in mac80211. Given that there's only simple code that needs
      to be done before calling it, export that function from cfg80211
      instead and let mac80211 call it itself.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      7f6990c8
    • J
      mac80211: discard multicast and 4-addr A-MSDUs · ea720935
      Johannes Berg 提交于
      In mac80211, multicast A-MSDUs are accepted in many cases that
      they shouldn't be accepted in:
       * drop A-MSDUs with a multicast A1 (RA), as required by the
         spec in 9.11 (802.11-2012 version)
       * drop A-MSDUs with a 4-addr header, since the fourth address
         can't actually be useful for them; unless 4-address frame
         format is actually requested, even though the fourth address
         is still not useful in this case, but ignored
      
      Accepting the first case, in particular, is very problematic
      since it allows anyone else with possession of a GTK to send
      unicast frames encapsulated in a multicast A-MSDU, even when
      the AP has client isolation enabled.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ea720935
  9. 30 9月, 2016 2 次提交
    • T
      mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue · bb42f2d1
      Toke Høiland-Jørgensen 提交于
      The TXQ intermediate queues can cause packet reordering when more than
      one flow is active to a single station. Since some of the wifi-specific
      packet handling (notably sequence number and encryption handling) is
      sensitive to re-ordering, things break if they are applied before the
      TXQ.
      
      This splits up the TX handlers and fast_xmit logic into two parts: An
      early part and a late part. The former is applied before TXQ enqueue,
      and the latter after dequeue. The non-TXQ path just applies both parts
      at once.
      
      Because fragments shouldn't be split up or reordered, the fragmentation
      handler is run after dequeue. Any fragments are then kept in the TXQ and
      on subsequent dequeues they take precedence over dequeueing from the FQ
      structure.
      
      This approach avoids having to scatter special cases all over the place
      for when TXQ is enabled, at the cost of making the fast_xmit and TX
      handler code slightly more complex.
      Signed-off-by: NToke Høiland-Jørgensen <toke@toke.dk>
      [fix a few code-style nits, make ieee80211_xmit_fast_finish void,
       remove a useless txq->sta check]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      bb42f2d1
    • A
      cfg80211: add start / stop NAN commands · cb3b7d87
      Ayala Beker 提交于
      This allows user space to start/stop NAN interface.
      A NAN interface is like P2P device in a few aspects: it
      doesn't have a netdev associated to it.
      Add the new interface type and prevent operations that
      can't be executed on NAN interface like scan.
      
      Define several attributes that may be configured by user space
      when starting NAN functionality (master preference and dual
      band operation)
      Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      cb3b7d87
  10. 20 9月, 2016 1 次提交
    • H
      mac80211: Use rhltable instead of rhashtable · 83e7e4ce
      Herbert Xu 提交于
      mac80211 currently uses rhashtable with insecure_elasticity set
      to true.  The latter is because of duplicate objects.  What's
      more, mac80211 walks the rhashtable chains by hand which is broken
      as rhashtable may contain multiple tables due to resizing or
      rehashing.
      
      This patch fixes it by converting it to the newly added rhltable
      interface which is designed for use with duplicate objects.
      
      With rhltable a lookup returns a list of objects instead of a
      single one.  This is then fed into the existing for_each_sta_info
      macro.
      
      This patch also deletes the sta_addr_hash function since rhashtable
      defaults to jhash.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83e7e4ce
  11. 12 9月, 2016 5 次提交
  12. 02 8月, 2016 1 次提交
  13. 30 6月, 2016 1 次提交
  14. 09 6月, 2016 1 次提交
    • M
      mac80211: implement fair queueing per txq · fa962b92
      Michal Kazior 提交于
      mac80211's software queues were designed to work
      very closely with device tx queues. They are
      required to make use of 802.11 packet aggregation
      easily and efficiently.
      
      Due to the way 802.11 aggregation is designed it
      only makes sense to keep fair queuing as close to
      hardware as possible to reduce induced latency and
      inertia and provide the best flow responsiveness.
      
      This change doesn't translate directly to
      immediate and significant gains. End result
      depends on driver's induced latency. Best results
      can be achieved if driver keeps its own tx
      queue/fifo fill level to a minimum.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      fa962b92
  15. 12 5月, 2016 1 次提交
    • J
      mac80211: allow software PS-Poll/U-APSD with AP_LINK_PS · 46fa38e8
      Johannes Berg 提交于
      When using RSS, frames might not be processed in the correct order,
      and thus AP_LINK_PS must be used; most likely with firmware keeping
      track of the powersave state, this is the case in iwlwifi now.
      
      In this case, the driver can use ieee80211_sta_ps_transition() to
      still have mac80211 manage powersave buffering. However, for U-APSD
      and PS-Poll this isn't sufficient. If the device can't manage that
      entirely on its own, mac80211's code should be used.
      
      To allow this, export two functions: ieee80211_sta_uapsd_trigger()
      and ieee80211_sta_pspoll().
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      46fa38e8
  16. 12 4月, 2016 1 次提交
  17. 06 4月, 2016 8 次提交
    • J
      mac80211: enable collecting station statistics per-CPU · c9c5962b
      Johannes Berg 提交于
      If the driver advertises the new HW flag USE_RSS, make the
      station statistics on the fast-rx path per-CPU. This will
      enable calling the RX in parallel, only hitting locking or
      shared cachelines when the fast-RX path isn't available.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c9c5962b
    • 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
    • J
      mac80211: fix RX u64 stats consistency on 32-bit platforms · 0f9c5a61
      Johannes Berg 提交于
      On 32-bit platforms, the 64-bit counters we keep need to be protected
      to be consistently read. Use the u64_stats_sync mechanism to do that.
      
      In order to not end up with overly long lines, refactor the tidstats
      assignments a bit.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      0f9c5a61
    • J
      mac80211: fix last RX rate data consistency · 4f6b1b3d
      Johannes Berg 提交于
      When storing the last_rate_* values in the RX code, there's nothing
      to guarantee consistency, so a concurrent reader could see, e.g.
      last_rate_idx on the new value, but last_rate_flag still on the old,
      getting completely bogus values in the end.
      
      To fix this, I lifted the sta_stats_encode_rate() function from my
      old rate statistics code, which encodes the entire rate data into a
      single 16-bit value, avoiding the consistency issue.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      4f6b1b3d
    • J
      mac80211: move averaged values out of rx_stats · 0be6ed13
      Johannes Berg 提交于
      Move the averaged values out of rx_stats and into rx_stats_avg,
      to cleanly split them out. The averaged ones cannot be supported
      for parallel RX in a per-CPU fashion, while the other values can
      be collected per CPU and then combined/selected when needed.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      0be6ed13
    • J
      mac80211: move semicolon out of CALL_RXH macro · 8ebaa5b0
      Johannes Berg 提交于
      Move the semicolon, people typically assume that and
      once line already put a semicolon behind the "call".
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8ebaa5b0
    • J
      mac80211: count MSDUs in A-MSDU properly · de8f18d3
      Johannes Berg 提交于
      For the RX MSDU statistics, we need to count the number of
      MSDUs created and accepted from an A-MSDU. Right now, all
      frames in any A-MSDUs were completely ignored. Fix this by
      moving the RX MSDU statistics accounting into the deliver
      function.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      de8f18d3
    • J
      mac80211: allow passing transmitter station on RX · d63b548f
      Johannes Berg 提交于
      Sometimes drivers already looked up, or know out-of-band
      from their device, which station transmitted a given RX
      frame. Allow them to pass the station pointer to mac80211
      to save the extra lookup.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d63b548f
  18. 05 4月, 2016 2 次提交
  19. 05 3月, 2016 1 次提交