1. 27 10月, 2016 3 次提交
  2. 19 10月, 2016 1 次提交
  3. 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
  4. 12 5月, 2016 1 次提交
  5. 12 4月, 2016 1 次提交
  6. 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
    • J
      mac80211: avoid useless memory write on each frame RX · b100e5d6
      Johannes Berg 提交于
      In the likely case that probe_count is 0, don't write to the
      memory there.
      
      Also use ifmgd consistently in the function, instead of using
      sdata->u.mgd as well.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b100e5d6
  7. 24 2月, 2016 3 次提交
  8. 26 1月, 2016 1 次提交
  9. 14 1月, 2016 2 次提交
  10. 15 12月, 2015 2 次提交
  11. 04 12月, 2015 1 次提交
  12. 03 11月, 2015 4 次提交
  13. 21 10月, 2015 1 次提交
  14. 15 10月, 2015 1 次提交
  15. 13 10月, 2015 1 次提交
  16. 29 9月, 2015 2 次提交
  17. 22 9月, 2015 4 次提交
    • J
      mac80211: use DECLARE_EWMA for ave_beacon_signal · 338c17ae
      Johannes Berg 提交于
      It doesn't seem problematic to change the weight for the average
      beacon signal from 3 to 4, so use DECLARE_EWMA. This also makes
      the code easier to maintain since bugs like the one fixed in the
      previous patch can't happen as easily.
      
      With a fix from Avraham Stern to invert the sign since EMWA uses
      unsigned values only.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      338c17ae
    • J
      mac80211: fix driver RSSI event calculations · 8ec6d978
      Johannes Berg 提交于
      The ifmgd->ave_beacon_signal value cannot be taken as is for
      comparisons, it must be divided by since it's represented
      like that for better accuracy of the EWMA calculations. This
      would lead to invalid driver RSSI events. Fix the used value.
      
      Fixes: 615f7b9b ("mac80211: add driver RSSI threshold events")
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8ec6d978
    • J
      mac80211: remove last_beacon/ave_beacon debugfs files · 8e0d7fe0
      Johannes Berg 提交于
      These file aren't really useful:
       - if per beacon data is required then you need to use
         radiotap or similar anyway, debugfs won't help much
       - average beacon signal is reported in station info in
         nl80211 and can be looked up with iw
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8e0d7fe0
    • J
      mac80211: remove direct probe step before authentication · 46cad4b7
      Johannes Berg 提交于
      The direct probe step before authentication was done mostly for
      two reasons:
       1) the BSS data could be stale
       2) the beacon might not have included all IEs
      
      The concern (1) doesn't really seem to be relevant any more as
      we time out BSS information after about 30 seconds, and in fact
      the original patch only did the direct probe if the data was
      older than the BSS timeout to begin with. This condition got
      (likely inadvertedly) removed later though.
      
      Analysing this in more detail shows that since we mostly use
      data from the association response, the only real reason for
      needing the probe response was that the code validates the WMM
      parameters, and those are optional in beacons. As the previous
      patches removed that behaviour, we can now remove the direct
      probe step entirely.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      46cad4b7
  18. 04 9月, 2015 1 次提交
  19. 17 7月, 2015 3 次提交
  20. 10 6月, 2015 2 次提交
    • J
      mac80211: convert HW flags to unsigned long bitmap · 30686bf7
      Johannes Berg 提交于
      As we're running out of hardware capability flags pretty quickly,
      convert them to use the regular test_bit() style unsigned long
      bitmaps.
      
      This introduces a number of helper functions/macros to set and to
      test the bits, along with new debugfs code.
      
      The occurrences of an explicit __clear_bit() are intentional, the
      drivers were never supposed to change their supported bits on the
      fly. We should investigate changing this to be a per-frame flag.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      30686bf7
    • M
      mac80211: release channel on auth failure · d01f858c
      Michal Kazior 提交于
      There were a few rare cases when upon
      authentication failure channel wasn't released.
      This could cause stale pointers to remain in
      chanctx assigned_vifs after interface removal and
      trigger general protection fault later.
      
      This could be triggered, e.g. on ath10k with the
      following steps:
      
       1. start an AP
       2. create 2 extra vifs on ath10k host
       3. connect vif1 to the AP
       4. connect vif2 to the AP
          (auth fails because ath10k firmware isn't able
           to maintain 2 peers with colliding AP mac
           addresses across vifs and consequently
           refuses sta_info_insert() in
           ieee80211_prep_connection())
       5. remove the 2 extra vifs
       6. goto step 2; at step 3 kernel was crashing:
      
       general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
       Modules linked in: ath10k_pci ath10k_core ath
       ...
       Call Trace:
        [<ffffffff81a2dabb>] ieee80211_check_combinations+0x22b/0x290
        [<ffffffff819fb825>] ? ieee80211_check_concurrent_iface+0x125/0x220
        [<ffffffff8180f664>] ? netpoll_poll_disable+0x84/0x100
        [<ffffffff819fb833>] ieee80211_check_concurrent_iface+0x133/0x220
        [<ffffffff81a0029e>] ieee80211_open+0x3e/0x80
        [<ffffffff817f2d26>] __dev_open+0xb6/0x130
        [<ffffffff817f3051>] __dev_change_flags+0xa1/0x170
       ...
       RIP  [<ffffffff81a23140>] ieee80211_chanctx_radar_detect+0xa0/0x170
      
       (gdb) l * ieee80211_chanctx_radar_detect+0xa0
       0xffffffff81a23140 is in ieee80211_chanctx_radar_detect (/devel/src/linux/net/mac80211/util.c:3182).
       3177             */
       3178            WARN_ON(ctx->replace_state == IEEE80211_CHANCTX_REPLACES_OTHER &&
       3179                    !list_empty(&ctx->assigned_vifs));
       3180
       3181            list_for_each_entry(sdata, &ctx->assigned_vifs, assigned_chanctx_list)
       3182                    if (sdata->radar_required)
       3183                            radar_detect |= BIT(sdata->vif.bss_conf.chandef.width);
       3184
       3185            return radar_detect;
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d01f858c
  21. 03 6月, 2015 1 次提交
  22. 01 6月, 2015 1 次提交
    • J
      mac80211: act upon and report deauth while associating · c9c99f89
      Johannes Berg 提交于
      When trying to associate, the AP could send a deauth frame instead.
      Currently mac80211 drops that frame and doesn't report it to the
      supplicant, which, in some versions and/or in certain circumstances
      will simply keep trying to associate over and over again instead of
      trying authentication again.
      
      Fix this by reacting to deauth frames while associating, reporting
      them to the supplicant and dropping the association attempt (which
      is bound to fail.)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c9c99f89
  23. 20 5月, 2015 1 次提交