1. 26 8月, 2014 1 次提交
  2. 15 8月, 2014 1 次提交
  3. 07 7月, 2014 1 次提交
  4. 23 6月, 2014 7 次提交
  5. 15 5月, 2014 4 次提交
  6. 20 3月, 2014 1 次提交
  7. 20 2月, 2014 1 次提交
    • E
      mac80211: fix AP powersave TX vs. wakeup race · 1d147bfa
      Emmanuel Grumbach 提交于
      There is a race between the TX path and the STA wakeup: while
      a station is sleeping, mac80211 buffers frames until it wakes
      up, then the frames are transmitted. However, the RX and TX
      path are concurrent, so the packet indicating wakeup can be
      processed while a packet is being transmitted.
      
      This can lead to a situation where the buffered frames list
      is emptied on the one side, while a frame is being added on
      the other side, as the station is still seen as sleeping in
      the TX path.
      
      As a result, the newly added frame will not be send anytime
      soon. It might be sent much later (and out of order) when the
      station goes to sleep and wakes up the next time.
      
      Additionally, it can lead to the crash below.
      
      Fix all this by synchronising both paths with a new lock.
      Both path are not fastpath since they handle PS situations.
      
      In a later patch we'll remove the extra skb queue locks to
      reduce locking overhead.
      
      BUG: unable to handle kernel
      NULL pointer dereference at 000000b0
      IP: [<ff6f1791>] ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
      *pde = 00000000
      Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      EIP: 0060:[<ff6f1791>] EFLAGS: 00210282 CPU: 1
      EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
      EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000
      ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0
      DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      DR6: ffff0ff0 DR7: 00000400
      Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000)
      iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9
      Stack:
       e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0
       ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210
       ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002
      Call Trace:
       [<ff6f1b75>] ieee80211_free_txskb+0x15/0x20 [mac80211]
       [<ff723dc1>] invoke_tx_handlers+0x1661/0x1780 [mac80211]
       [<ff7248a5>] ieee80211_tx+0x75/0x100 [mac80211]
       [<ff7249bf>] ieee80211_xmit+0x8f/0xc0 [mac80211]
       [<ff72550e>] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211]
       [<c149ef70>] dev_hard_start_xmit+0x450/0x950
       [<c14b9aa9>] sch_direct_xmit+0xa9/0x250
       [<c14b9c9b>] __qdisc_run+0x4b/0x150
       [<c149f732>] dev_queue_xmit+0x2c2/0xca0
      
      Cc: stable@vger.kernel.org
      Reported-by: NYaara Rozenblum <yaara.rozenblum@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Reviewed-by: NStanislaw Gruszka <sgruszka@redhat.com>
      [reword commit log, use a separate lock]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1d147bfa
  8. 06 2月, 2014 1 次提交
    • J
      mac80211: fix fragmentation code, particularly for encryption · 338f977f
      Johannes Berg 提交于
      The "new" fragmentation code (since my rewrite almost 5 years ago)
      erroneously sets skb->len rather than using skb_trim() to adjust
      the length of the first fragment after copying out all the others.
      This leaves the skb tail pointer pointing to after where the data
      originally ended, and thus causes the encryption MIC to be written
      at that point, rather than where it belongs: immediately after the
      data.
      
      The impact of this is that if software encryption is done, then
       a) encryption doesn't work for the first fragment, the connection
          becomes unusable as the first fragment will never be properly
          verified at the receiver, the MIC is practically guaranteed to
          be wrong
       b) we leak up to 8 bytes of plaintext (!) of the packet out into
          the air
      
      This is only mitigated by the fact that many devices are capable
      of doing encryption in hardware, in which case this can't happen
      as the tail pointer is irrelevant in that case. Additionally,
      fragmentation is not used very frequently and would normally have
      to be configured manually.
      
      Fix this by using skb_trim() properly.
      
      Cc: stable@vger.kernel.org
      Fixes: 2de8e0d9 ("mac80211: rewrite fragmentation")
      Reported-by: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      338f977f
  9. 05 2月, 2014 3 次提交
    • J
      mac80211: fix bufferable MMPDU RX handling · b4ba544c
      Johannes Berg 提交于
      Action, disassoc and deauth frames are bufferable, and as such don't
      have the PM bit in the frame control field reserved which means we
      need to react to the bit when receiving in such a frame.
      
      Fix this by introducing a new helper ieee80211_is_bufferable_mmpdu()
      and using it for the RX path that currently ignores the PM bit in
      any non-data frames for doze->wake transitions, but listens to it in
      all frames for wake->doze transitions, both of which are wrong.
      
      Also use the new helper in the TX path to clean up the code.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b4ba544c
    • J
      mac80211: add length check in ieee80211_is_robust_mgmt_frame() · d8ca16db
      Johannes Berg 提交于
      A few places weren't checking that the frame passed to the
      function actually has enough data even though the function
      clearly documents it must have a payload byte. Make this
      safer by changing the function to take an skb and checking
      the length inside. The old version is preserved for now as
      the rtl* drivers use it and don't have a correct skb.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d8ca16db
    • L
      mac80211: only set CSA beacon when at least one beacon must be transmitted · 66e01cf9
      Luciano Coelho 提交于
      A beacon should never have a Channel Switch Announcement information
      element with a count of 0, because a count of 1 means switch just
      before the next beacon.  So, if a count of 0 was valid in a beacon, it
      would have been transmitted in the next channel already, which is
      useless.  A CSA count equal to zero is only meaningful in action
      frames or probe_responses.
      
      Fix the ieee80211_csa_is_complete() and ieee80211_update_csa()
      functions accordingly.
      
      With a CSA count of 0, we won't transmit any CSA beacons, because the
      switch will happen before the next TBTT.  To avoid extra work and
      potential confusion in the drivers, complete the CSA immediately,
      instead of waiting for the driver to call ieee80211_csa_finish().
      
      To keep things simpler, we also switch immediately when the CSA count
      is 1, while in theory we should delay the switch until just before the
      next TBTT.
      
      Additionally, move the ieee80211_csa_finish() function to cfg.c,
      where it makes more sense.
      Tested-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Acked-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      66e01cf9
  10. 10 1月, 2014 1 次提交
  11. 18 12月, 2013 1 次提交
  12. 17 12月, 2013 1 次提交
  13. 16 12月, 2013 2 次提交
  14. 02 12月, 2013 1 次提交
  15. 26 11月, 2013 2 次提交
    • M
      mac80211: add generic cipher scheme support · 2475b1cc
      Max Stepanov 提交于
      This adds generic cipher scheme support to mac80211, such schemes
      are fully under control by the driver. On hw registration drivers
      may specify additional HW ciphers with a scheme how these ciphers
      have to be handled by mac80211 TX/RR. A cipher scheme specifies a
      cipher suite value, a size of the security header to be added to
      or stripped from frames and how the PN is to be verified on RX.
      Signed-off-by: NMax Stepanov <Max.Stepanov@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      2475b1cc
    • L
      cfg80211: consolidate passive-scan and no-ibss flags · 8fe02e16
      Luis R. Rodriguez 提交于
      These two flags are used for the same purpose, just
      combine them into a no-ir flag to annotate no initiating
      radiation is allowed.
      
      Old userspace sending either flag will have it treated as
      the no-ir flag. To be considerate to older userspace we
      also send both the no-ir flag and the old no-ibss flags.
      Newer userspace will have to be aware of older kernels.
      
      Update all places in the tree using these flags with the
      following semantic patch:
      
      @@
      @@
      -NL80211_RRF_PASSIVE_SCAN
      +NL80211_RRF_NO_IR
      @@
      @@
      -NL80211_RRF_NO_IBSS
      +NL80211_RRF_NO_IR
      @@
      @@
      -IEEE80211_CHAN_PASSIVE_SCAN
      +IEEE80211_CHAN_NO_IR
      @@
      @@
      -IEEE80211_CHAN_NO_IBSS
      +IEEE80211_CHAN_NO_IR
      @@
      @@
      -NL80211_RRF_NO_IR | NL80211_RRF_NO_IR
      +NL80211_RRF_NO_IR
      @@
      @@
      -IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_NO_IR
      +IEEE80211_CHAN_NO_IR
      @@
      @@
      -(NL80211_RRF_NO_IR)
      +NL80211_RRF_NO_IR
      @@
      @@
      -(IEEE80211_CHAN_NO_IR)
      +IEEE80211_CHAN_NO_IR
      
      Along with some hand-optimisations in documentation, to
      remove duplicates and to fix some indentation.
      Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
      [do all the driver updates in one go]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8fe02e16
  16. 28 10月, 2013 2 次提交
  17. 30 9月, 2013 1 次提交
  18. 26 9月, 2013 2 次提交
  19. 23 8月, 2013 1 次提交
  20. 12 8月, 2013 1 次提交
    • J
      mac80211: add control port protocol TX control flag · af61a165
      Johannes Berg 提交于
      A lot of drivers check the frame protocol for ETH_P_PAE,
      for various reasons (like making those more reliable).
      Add a new flags bitmap to the TX control info and a new
      flag indicating the control port protocol is in use to
      let all drivers also apply such logic to other control
      port protocols, should they be configured.
      
      Also use the new flag in the iwlwifi drivers.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      af61a165
  21. 02 8月, 2013 1 次提交
  22. 01 8月, 2013 1 次提交
  23. 16 7月, 2013 3 次提交