1. 15 Dec, 2015 2 commits
  2. 03 Nov, 2015 4 commits
  3. 21 Oct, 2015 1 commit
  4. 14 Oct, 2015 1 commit
  5. 13 Oct, 2015 1 commit
  6. 29 Sep, 2015 2 commits
  7. 22 Sep, 2015 4 commits
    • Johannes Berg's avatar
      mac80211: use DECLARE_EWMA for ave_beacon_signal · 338c17ae
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      338c17ae
    • Johannes Berg's avatar
      mac80211: fix driver RSSI event calculations · 8ec6d978
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      8ec6d978
    • Johannes Berg's avatar
      mac80211: remove last_beacon/ave_beacon debugfs files · 8e0d7fe0
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      8e0d7fe0
    • Johannes Berg's avatar
      mac80211: remove direct probe step before authentication · 46cad4b7
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      46cad4b7
  8. 04 Sep, 2015 1 commit
  9. 17 Jul, 2015 3 commits
  10. 10 Jun, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: convert HW flags to unsigned long bitmap · 30686bf7
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      30686bf7
  11. 09 Jun, 2015 1 commit
    • Michal Kazior's avatar
      mac80211: release channel on auth failure · d01f858c
      Michal Kazior authored
      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: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      d01f858c
  12. 02 Jun, 2015 1 commit
  13. 01 Jun, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: act upon and report deauth while associating · c9c99f89
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      c9c99f89
  14. 20 May, 2015 1 commit
  15. 24 Apr, 2015 1 commit
  16. 01 Apr, 2015 1 commit
  17. 30 Mar, 2015 7 commits
  18. 16 Mar, 2015 3 commits
  19. 04 Mar, 2015 2 commits
  20. 03 Mar, 2015 2 commits
    • Joe Perches's avatar
      mac80211: Use eth_<foo>_addr instead of memset · c84a67a2
      Joe Perches authored
      Use the built-in function instead of memset.
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c84a67a2
    • Johannes Berg's avatar
      mac80211: fix another suspend vs. association race · be72afe0
      Johannes Berg authored
      Since cfg80211 disconnects, but has no insight into the association
      process, it can happen that it disconnects while association is in
      progress. We then try to abort association in mac80211, but this is
      only later so the association can complete between the two.
      
      This results in removing an interface from the driver while bound
      to the channel context, obviously causing confusion and issues.
      
      Solve this by also checking if we're associated during quiesce and
      if so deauthenticating. The frame will no longer go out to the AP
      which is a bit unfortunate, but it'll resolve the crash (and before
      we would have suspended without telling the AP as well.)
      
      I'm working on a better, but more complex solution as well, which
      should avoid that problem.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      be72afe0