1. 06 3月, 2013 2 次提交
  2. 18 1月, 2013 1 次提交
  3. 19 11月, 2012 2 次提交
  4. 06 9月, 2012 1 次提交
  5. 09 7月, 2012 1 次提交
  6. 24 6月, 2012 1 次提交
    • J
      mac80211: clean up debugging · bdcbd8e0
      Johannes Berg 提交于
      There are a few things that make the logging and
      debugging in mac80211 less useful than it should
      be right now:
       * a lot of messages should be pr_info, not pr_debug
       * wholesale use of pr_debug makes it require *both*
         Kconfig and dynamic configuration
       * there are still a lot of ifdefs
       * the style is very inconsistent, sometimes the
         sdata->name is printed in front
      
      Clean up everything, introducing new macros and
      separating out the station MLME debugging into
      a new Kconfig symbol.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      bdcbd8e0
  7. 28 2月, 2012 1 次提交
  8. 07 2月, 2012 2 次提交
  9. 09 11月, 2011 1 次提交
  10. 01 11月, 2011 1 次提交
  11. 01 10月, 2011 1 次提交
    • J
      mac80211: optimise station flags · c2c98fde
      Johannes Berg 提交于
      The flaglock in struct sta_info has long been
      something that I wanted to get rid of, this
      finally does the conversion to atomic bitops.
      
      The conversion itself is straight-forward in
      most places, a few things needed to change a
      bit since we can no longer use multiple bits
      at the same time.
      
      On x86-64, this is a fairly significant code
      size reduction:
         text	   data	    bss	    dec	    hex
       427861	  23648	   1008	 452517	  6e7a5	before
       425383	  23648	    976	 450007	  6ddd7	after
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c2c98fde
  12. 16 7月, 2011 1 次提交
  13. 08 7月, 2011 2 次提交
    • J
      mac80211: allow drivers to access key sequence counter · 3ea542d3
      Johannes Berg 提交于
      In order to implement GTK rekeying, the device needs
      to be able to encrypt frames with the right PN/IV and
      check the PN/IV in RX frames. To be able to tell it
      about all those counters, we need to be able to get
      them from mac80211, this adds the required API.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3ea542d3
    • J
      mac80211: fix TKIP races, make API easier to use · 523b02ea
      Johannes Berg 提交于
      Our current TKIP code races against itself on TX
      since we can process multiple packets at the same
      time on different ACs, but they all share the TX
      context for TKIP. This can lead to bad IVs etc.
      
      Also, the crypto offload helper code just obtains
      the P1K/P2K from the cache, and can update it as
      well, but there's no guarantee that packets are
      really processed in order.
      
      To fix these issues, first introduce a spinlock
      that will protect the IV16/IV32 values in the TX
      context. This first step makes sure that we don't
      assign the same IV multiple times or get confused
      in other ways.
      
      Secondly, change the way the P1K cache works. I
      add a field "p1k_iv32" that stores the value of
      the IV32 when the P1K was last recomputed, and
      if different from the last time, then a new P1K
      is recomputed. This can cause the P1K computation
      to flip back and forth if packets are processed
      out of order. All this also happens under the new
      spinlock.
      
      Finally, because there are argument differences,
      split up the ieee80211_get_tkip_key() API into
      ieee80211_get_tkip_p1k() and ieee80211_get_tkip_p2k()
      and give them the correct arguments.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      523b02ea
  14. 07 7月, 2011 2 次提交
  15. 06 7月, 2011 1 次提交
  16. 07 6月, 2011 1 次提交
  17. 17 5月, 2011 1 次提交
    • J
      mac80211: sparse RCU annotations · 40b275b6
      Johannes Berg 提交于
      This adds sparse RCU annotations to most of
      mac80211, only the mesh code remains to be
      done.
      
      Due the the previous patches, the annotations
      are pretty simple. The only thing that this
      actually changes is removing the RCU usage of
      key->sta in debugfs since this pointer isn't
      actually an RCU-managed pointer (it only has
      a single assignment done before the key even
      goes live). As that is otherwise harmless, I
      decided to make it part of this patch.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      40b275b6
  18. 13 5月, 2011 1 次提交
  19. 05 5月, 2011 1 次提交
    • M
      mac80211: Fix a warning due to skipping tailroom reservation for IV · eaef6a93
      Mohammed Shafi Shajakhan 提交于
      The devices that require IV generation in software need tailroom
      reservation  for ICVs used in TKIP or WEP encryptions.
      Currently, decision to skip the tailroom reservation in the tx
      path was taken only on whether driver wants MMIC to be generated
      in software or not. Following patch appends IV generation check for
      such decisions and fixes the following warning.
      
      WARNING: at net/mac80211/wep.c:101 ieee80211_wep_add_iv+0x56/0xf3()
      Hardware name: 64756D6
      Modules linked in: ath9k ath9k_common ath9k_hw
      Pid: 0, comm: swapper Tainted: G        W   2.6.39-rc5-wl
       Call Trace:
      [<c102fd29>] warn_slowpath_common+0x65/0x7a
      [<c1465c4e>] ? ieee80211_wep_add_iv+0x56/0xf3
      [<c102fd4d>] warn_slowpath_null+0xf/0x13
      [<c1465c4e>] ieee80211_wep_add_iv+0x56/0xf3
      [<c1466007>] ieee80211_crypto_wep_encrypt+0x63/0x88
      [<c1478bf3>] ieee80211_tx_h_encrypt+0x2f/0x63
      [<c1478cba>] invoke_tx_handlers+0x93/0xe1
      [<c1478eda>] ieee80211_tx+0x4b/0x6d
      [<c147907c>] ieee80211_xmit+0x180/0x188
      [<c147779d>] ? ieee80211_skb_resize+0x95/0xd9
      [<c1479edf>] ieee80211_subif_start_xmit+0x64f/0x668
      [<c13956fc>] dev_hard_start_xmit+0x368/0x48c
      [<c13a8bd6>] sch_direct_xmit+0x4d/0x101
      [<c1395ae1>] dev_queue_xmit+0x2c1/0x43f
      [<c13a74a2>] ? eth_header+0x1e/0x90
      [<c13a7400>] ? eth_type_trans+0x91/0xc2
      [<c13a7484>] ? eth_rebuild_header+0x53/0x53
      [<c139f079>] neigh_resolve_output+0x223/0x27e
      [<c13c6b23>] ip_finish_output2+0x1d4/0x1fe
      [<c13c6bc6>] ip_finish_output+0x79/0x7d
      [<c13c6cbe>] T.1075+0x43/0x48
      [<c13c6e6e>] ip_output+0x75/0x7b
      [<c13c4970>] dst_output+0xc/0xe
      [<c13c62c9>] ip_local_out+0x17/0x1a
      [<c13c67bb>] ip_queue_xmit+0x2aa/0x2f8
      [<c138b742>] ? sk_setup_caps+0x21/0x92
      [<c13d95ea>] ? __tcp_v4_send_check+0x7e/0xb7
      [<c13d5d2e>] tcp_transmit_skb+0x6a1/0x6d7
      [<c13d533b>] ? tcp_established_options+0x20/0x8b
      [<c13d6f28>] tcp_retransmit_skb+0x43a/0x527
      [<c13d8d6d>] tcp_retransmit_timer+0x32e/0x45d
      [<c13d8f23>] tcp_write_timer+0x87/0x16c
      [<c103a030>] run_timer_softirq+0x156/0x1f9
      [<c13d8e9c>] ? tcp_retransmit_timer+0x45d/0x45d
      [<c1034d65>] __do_softirq+0x97/0x14a
      [<c1034cce>] ? irq_enter+0x4d/0x4d
      
      Cc: Yogesh Powar <yogeshp@marvell.com>
      Reported-by: NFabio Rossi <rossi.f@inwind.it>
      Tested-by: NFabio Rossi <rossi.f@inwind.it>
      Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      eaef6a93
  20. 29 4月, 2011 1 次提交
  21. 29 3月, 2011 2 次提交
  22. 05 1月, 2011 2 次提交
  23. 14 12月, 2010 1 次提交
  24. 23 11月, 2010 1 次提交
    • H
      mac80211: Disable hw crypto for GTKs on AP VLAN interfaces · 18890d4b
      Helmut Schaa 提交于
      When using AP VLAN interfaces, each VLAN interface should be in its own
      broadcast domain. Hostapd achieves this by assigning different GTKs to
      different AP VLAN interfaces.
      
      However, mac80211 drivers are not aware of AP VLAN interfaces and as
      such mac80211 sends the GTK to the driver in the context of the base AP
      mode interface. This causes problems when multiple AP VLAN interfaces
      are used since the driver will use the same key slot for the different
      GTKs (there's no way for the driver to distinguish the different GTKs
      from different AP VLAN interfaces). Thus, only the clients associated
      to one AP VLAN interface (the one that was created last) can actually
      use broadcast traffic.
      
      Fix this by not programming any GTKs for AP VLAN interfaces into the hw
      but fall back to using software crypto. The GTK for the underlying AP
      interface is still sent to the driver.
      
      That means, broadcast traffic to stations associated to an AP VLAN
      interface is encrypted in software whereas broadcast traffic to
      stations associated to the non-VLAN AP interface is encrypted in
      hardware.
      
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      18890d4b
  25. 07 10月, 2010 1 次提交
  26. 17 9月, 2010 1 次提交
  27. 28 8月, 2010 1 次提交
  28. 26 8月, 2010 1 次提交
  29. 17 8月, 2010 3 次提交
  30. 28 7月, 2010 1 次提交
    • J
      mac80211: Fix key freeing to handle unlinked keys · 32162a4d
      Jouni Malinen 提交于
      Key locking simplification removed key->sdata != NULL verification from
      ieee80211_key_free(). While that is fine for most use cases, there is one
      path where this function can be called with an unlinked key (i.e.,
      key->sdata == NULL && key->local == NULL). This results in a NULL pointer
      dereference with the current implementation. This is known to happen at
      least with FT protocol when wpa_supplicant tries to configure the key
      before association.
      
      Avoid the issue by passing in the local pointer to
      ieee80211_key_free(). In addition, do not clear the key from hw_accel
      or debugfs if it has not yet been added. At least the hw_accel one could
      trigger another NULL pointer dereference.
      Signed-off-by: NJouni Malinen <j@w1.fi>
      Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      32162a4d
  31. 16 6月, 2010 1 次提交