1. 05 Apr, 2016 1 commit
  2. 01 Mar, 2016 1 commit
    • Johannes Berg's avatar
      mac80211: check PN correctly for GCMP-encrypted fragmented MPDUs · 9acc54be
      Johannes Berg authored
      Just like for CCMP we need to check that for GCMP the fragments
      have PNs that increment by one; the spec was updated to fix this
      security issue and now has the following text:
      	The receiver shall discard MSDUs and MMPDUs whose constituent
      	MPDU PN values are not incrementing in steps of 1.
      Adapt the code for CCMP to work for GCMP as well, luckily the
      relevant fields already alias each other so no code duplication
      is needed (just check the aliasing with BUILD_BUG_ON.)
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  3. 24 Feb, 2016 5 commits
  4. 14 Jan, 2016 1 commit
  5. 15 Dec, 2015 1 commit
  6. 04 Dec, 2015 3 commits
    • Johannes Berg's avatar
      mac80211: rewrite remain-on-channel logic · aaa016cc
      Johannes Berg authored
      Jouni found a bug in the remain-on-channel logic: when a short item
      is queued, a long item is combined with it extending the original
      one, and then the long item is deleted, the timeout doesn't go back
      to the short one, and the short item ends up taking a long time. In
      this case, this showed as blocking scan when running two test cases
      back to back - the scan from the second was delayed even though all
      the remain-on-channel items should long have been gone.
      Fixing this with the current data structures turns out to be a bit
      complicated, we just remove the long item from the dependents list
      right now and don't recalculate the timeouts.
      There's a somewhat similar bug where we delete the short item and
      all the dependents go with it; to fix this we'd have to move them
      from the dependents to the real list.
      Instead of trying to do that, rewrite the code to not have all this
      complexity in the data structures: use a single list and allow more
      than one entry in it being marked as started. This makes the code a
      bit more complex, the worker needs to understand that it might need
      to just remove one of the started items, while keeping the device
      off-channel, but that's not more complicated than the nested data
      This then fixes both issues described, and makes it easier to also
      limit the overall off-channel time when combining.
      TODO: as before, with hardware remain-on-channel, deleting an item
      after combining results in cancelling them all - we can keep track
      of the time elapsed and only cancel after that to fix this.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: simplify ack_skb handling · 5ee00dbd
      Johannes Berg authored
      Since the cookie is assigned inside ieee80211_make_ack_skb()
      now, we no longer need to return the ack_skb as the cookie
      and can simplify the function's return and the callers. Also
      rename it to ieee80211_attach_ack_skb() to more accurately
      reflect its purpose.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: move off-channel/mgmt-tx code to offchannel.c · a2fcfccb
      Johannes Berg authored
      This is quite a bit of code that logically depends here since
      it has to deal with all the remain-on-channel logic.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  7. 03 Nov, 2015 3 commits
  8. 21 Oct, 2015 1 commit
  9. 14 Oct, 2015 3 commits
  10. 29 Sep, 2015 1 commit
  11. 22 Sep, 2015 4 commits
  12. 14 Aug, 2015 1 commit
  13. 17 Jul, 2015 9 commits
  14. 20 May, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: don't split remain-on-channel for coalescing · 252ec2b3
      Johannes Berg authored
      Due to remain-on-channel scheduling delays, when we split an ROC
      while coalescing, we'll usually get a picture like this:
      existing ROC:  |------------------|
      current time:              ^
      new ROC:                   |------|              |-------|
      If the expected response frames are then transmitted by the peer
      in the hole between the two fragments of the new ROC, we miss
      them and the process (e.g. ANQP query) fails.
      mac80211 expects that the window to miss something is small:
      existing ROC:  |------------------|
      new ROC:                   |------||-------|
      but that's normally not the case.
      To avoid this problem, coalesce only if the new ROC's duration
      is <= the remaining time on the existing one:
      existing ROC:  |------------------|
      new ROC:                   |-----|
      and never split a new one but schedule it afterwards instead:
      existing ROC:  |------------------|
      new ROC:                                       |-------------|
      Reported-by: default avatarMatti Gottlieb <matti.gottlieb@intel.com>
      Reviewed-by: default avatarEliadX Peller <eliad@wizery.com>
      Reviewed-by: default avatarMatti Gottlieb <matti.gottlieb@intel.com>
      Tested-by: default avatarMatti Gottlieb <matti.gottlieb@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  15. 19 May, 2015 1 commit
  16. 11 May, 2015 1 commit
  17. 05 May, 2015 3 commits
    • Johannes Berg's avatar
      mac80211: make LED triggering depend on activation · 8d5c2585
      Johannes Berg authored
      When LED triggers are compiled in, but not used, mac80211 will still
      call them to update the status. This isn't really a problem for the
      assoc and radio ones, but the TX/RX (and to a certain extend TPT)
      ones can be called very frequently (for every packet.)
      In order to avoid that when they're not used, track their activation
      and call the corresponding trigger (and in the TPT case, account for
      throughput) only when the trigger is actually used by an LED.
      Additionally, make those trigger functions inlines since theyre only
      used once in the remaining code.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: move dot11 counters under MAC80211_DEBUG_COUNTERS · c206ca67
      Johannes Berg authored
      Since these counters can only be read through debugfs, there's
      very little point in maintaining them all the time. However,
      even just making them depend on debugfs is pointless - they're
      not normally used. Additionally a number of them aren't even
      concurrency safe.
      Move them under MAC80211_DEBUG_COUNTERS so they're normally
      not even compiled in.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Johannes Berg's avatar
      mac80211: clean up global debugfs statistics · f1160434
      Johannes Berg authored
      The debugfs statistics macros are pointlessly verbose, so change
      that macro to just have a single argument. While at it, remove
      the unused counters and rename rx_expand_skb_head2 to the better
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>