An error occurred fetching the project authors.
  1. 16 Sep, 2010 4 commits
  2. 31 Aug, 2010 2 commits
  3. 27 Aug, 2010 2 commits
  4. 25 Aug, 2010 1 commit
  5. 16 Aug, 2010 3 commits
  6. 29 Jul, 2010 1 commit
  7. 21 Jul, 2010 1 commit
  8. 20 Jul, 2010 1 commit
    • Johannes Berg's avatar
      mac80211: move QoS-enable to BSS info · 4ced3f74
      Johannes Berg authored
      Ever since
      
      commit e1b3ec1a
      Author: Stanislaw Gruszka <sgruszka@redhat.com>
      Date:   Mon Mar 29 12:18:34 2010 +0200
      
          mac80211: explicitly disable/enable QoS
      
      mac80211 is telling drivers, in particular
      iwlwifi, whether QoS is enabled or not.
      
      However, this is only relevant for station mode,
      since only then will any device send nullfunc
      frames and need to know whether they should be
      QoS frames or not. In other modes, there are
      (currently) no frames the device is supposed to
      send.
      
      When you now consider virtual interfaces, it
      becomes apparent that the current mechanism is
      inadequate since it enables/disables QoS on a
      global scale, where for nullfunc frames it has
      to be on a per-interface scale.
      
      Due to the above considerations, we can change
      the way mac80211 advertises the QoS state to
      drivers to only ever advertise it as "off" in
      station mode, and make it a per-BSS setting.
      Tested-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4ced3f74
  9. 21 Jun, 2010 1 commit
    • Juuso Oikarinen's avatar
      mac80211: Add interface for driver to temporarily disable dynamic ps · f90754c1
      Juuso Oikarinen authored
      This mechanism introduced in this patch applies (at least) for hardware
      designs using a single shared antenna for both WLAN and BT. In these designs,
      the antenna must be toggled between WLAN and BT.
      
      In those hardware, managing WLAN co-existence with Bluetooth requires WLAN
      full power save whenever there is Bluetooth activity in order for WLAN to be
      able to periodically relinquish the antenna to be used for BT. This is because
      BT can only access the shared antenna when WLAN is idle or asleep.
      
      Some hardware, for instance the wl1271, are able to indicate to the host
      whenever there is BT traffic. In essence, the hardware will send an indication
      to the host whenever there is, for example, SCO traffic or A2DP traffic, and
      will send another indication when the traffic is over.
      
      The hardware gets information of Bluetooth traffic via hardware co-existence
      control lines - these lines are used to negotiate the shared antenna
      ownership. The hardware will give the antenna to BT whenever WLAN is sleeping.
      
      This patch adds the interface to mac80211 to facilitate temporarily disabling
      of dynamic power save as per request of the WLAN driver. This interface will
      immediately force WLAN to full powersave, hence allowing BT coexistence as
      described above.
      
      In these kind of shared antenna desings, when WLAN powersave is fully disabled,
      Bluetooth will not work simultaneously with WLAN at all. This patch does not
      address that problem. This interface will not change PSM state, so if PSM is
      disabled it will remain so. Solving this problem requires knowledge about BT
      state, and is best done in user-space.
      Signed-off-by: default avatarJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f90754c1
  10. 15 Jun, 2010 2 commits
    • Jouni Malinen's avatar
      mac80211: Protect Deauthentication frame when using MFP · 05e48e8e
      Jouni Malinen authored
      When management frame protection (IEEE 802.11w) is used,
      Deauthentication frame needs to be protected when the pairwise key is
      configured. mac80211 was removing the station entry (and its keys)
      before actually sending out the Deauthentication frame. Fix this by
      reordering the code to send the frame before the station entry gets
      removed. This matches an earlier change that handled the Disassociation
      frame processing, but missed Deauthentication frames.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      05e48e8e
    • Juuso Oikarinen's avatar
      mac80211: Fix ps-qos network latency handling · ff616381
      Juuso Oikarinen authored
      The ps-qos latency handling is broken. It uses predetermined latency values
      to select specific dynamic PS timeouts. With common AP configurations, these
      values overlap with beacon interval and are therefore essentially useless
      (for network latencies less than the beacon interval, PSM is disabled.)
      
      This patch remedies the problem by replacing the predetermined network latency
      values with one high value (1900ms) which is used to go trigger full psm. For
      backwards compatibility, the value 2000ms is still mapped to a dynamic ps
      timeout of 100ms.
      
      Currently also the mac80211 internal value for storing user space configured
      dynamic PSM values is incorrectly in the driver visible ieee80211_conf struct.
      Move it to the ieee80211_local struct.
      Signed-off-by: default avatarJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ff616381
  11. 14 Jun, 2010 9 commits
    • Juuso Oikarinen's avatar
      mac80211: Fix circular locking dependency in ARP filter handling · 68542962
      Juuso Oikarinen authored
      There is a circular locking dependency when configuring the
      hardware ARP filters on association, occurring when flushing the mac80211
      workqueue. This is what happens:
      
      [   92.026800] =======================================================
      [   92.030507] [ INFO: possible circular locking dependency detected ]
      [   92.030507] 2.6.34-04781-g2b2c009e #85
      [   92.030507] -------------------------------------------------------
      [   92.030507] modprobe/5225 is trying to acquire lock:
      [   92.030507]  ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<ffffffff8105b5c0>] flush_workq
      ueue+0x0/0xb0
      [   92.030507]
      [   92.030507] but task is already holding lock:
      [   92.030507]  (rtnl_mutex){+.+.+.}, at: [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20
      [   92.030507]
      [   92.030507] which lock already depends on the new lock.
      [   92.030507]
      [   92.030507]
      [   92.030507] the existing dependency chain (in reverse order) is:
      [   92.030507]
      [   92.030507] -> #2 (rtnl_mutex){+.+.+.}:
      [   92.030507]        [<ffffffff810761fb>] lock_acquire+0xdb/0x110
      [   92.030507]        [<ffffffff81341754>] mutex_lock_nested+0x44/0x300
      [   92.030507]        [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20
      [   92.030507]        [<ffffffffa022d47c>] ieee80211_assoc_done+0x6c/0xe0 [mac80211]
      [   92.030507]        [<ffffffffa022f2ad>] ieee80211_work_work+0x31d/0x1280 [mac80211]
      
      [   92.030507] -> #1 ((&local->work_work)){+.+.+.}:
      [   92.030507]        [<ffffffff810761fb>] lock_acquire+0xdb/0x110
      [   92.030507]        [<ffffffff8105a51a>] worker_thread+0x22a/0x370
      [   92.030507]        [<ffffffff8105ecc6>] kthread+0x96/0xb0
      [   92.030507]        [<ffffffff81003a94>] kernel_thread_helper+0x4/0x10
      [   92.030507]
      [   92.030507] -> #0 ((wiphy_name(local->hw.wiphy))){+.+.+.}:
      [   92.030507]        [<ffffffff81075fdc>] __lock_acquire+0x1c0c/0x1d50
      [   92.030507]        [<ffffffff810761fb>] lock_acquire+0xdb/0x110
      [   92.030507]        [<ffffffff8105b60e>] flush_workqueue+0x4e/0xb0
      [   92.030507]        [<ffffffffa023ff7b>] ieee80211_stop_device+0x2b/0xb0 [mac80211]
      [   92.030507]        [<ffffffffa0231635>] ieee80211_stop+0x3e5/0x680 [mac80211]
      
      The locking in this case is quite complex. Fix the problem by rewriting the
      way the hardware ARP filter list is handled - i.e. make a copy of the address
      list to the bss_conf struct, and provide that list to the hardware driver
      when needed.
      
      The current patch will enable filtering also in promiscuous mode. This may need
      to be changed in the future.
      Reported-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      68542962
    • Johannes Berg's avatar
      mac80211: always process blockack action from workqueue · bed7ee6e
      Johannes Berg authored
      To prepare for making the ampdu_action callback
      sleep, make mac80211 always process blockack
      action frames from the skb queue. This gets rid
      of the current special case for managed mode
      interfaces as well.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      bed7ee6e
    • Johannes Berg's avatar
      mac80211: pull mgmt frame rx into rx handler · 77a121c3
      Johannes Berg authored
      Some code is duplicated between ibss, mesh and
      managed mode regarding the queueing of management
      frames. Since all modes now use a common skb
      queue and a common work function, we can pull
      the queueing code into the rx handler directly
      and remove the duplicated length checks etc.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      77a121c3
    • Johannes Berg's avatar
      mac80211: common work skb freeing · 36b3a628
      Johannes Berg authored
      All the management processing functions free the
      skb after they are done, so this can be done in
      the new common code instead.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      36b3a628
    • Johannes Berg's avatar
      mac80211: use common work function · 1fa57d01
      Johannes Berg authored
      Even with the previous patch, IBSS, managed
      and mesh modes all attach their own work
      function to the shared work struct, which
      means some duplicated code. Change that to
      only have a frame processing function and a
      further work function for each of them and
      share some common code.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      1fa57d01
    • Johannes Berg's avatar
      mac80211: use common work struct · 64592c8f
      Johannes Berg authored
      IBSS, managed and mesh modes all have their
      own work struct, and in the future we want
      to also use it in other modes to process
      frames from the now common skb queue.
      
      This also makes the skb queue and work safe
      to use from other interface types.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      64592c8f
    • Johannes Berg's avatar
      mac80211: use common skb queue · 35f20c14
      Johannes Berg authored
      IBSS, managed and mesh modes all have an
      skb queue, and in the future we want to
      also use it in other modes, so make them
      all use a common skb queue already.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      35f20c14
    • Johannes Berg's avatar
      mac80211: simplify station/aggregation code · 2a419056
      Johannes Berg authored
      A number of places use RCU locking for accessing
      the station list, even though they do not need
      to. Use mutex locking instead to prepare for the
      locking changes I want to make. The mlme code is
      also using a WLAN_STA_DISASSOC flag that has the
      same meaning as WLAN_STA_BLOCK_BA, so use that.
      
      While doing so, combine places where we loop
      over stations twice, and optimise away some of
      the loops by checking if the hardware supports
      aggregation at all first.
      
      Also fix a more theoretical race condition: right
      now we could resume, set up an aggregation session,
      and right after tear it down again due to the code
      that is needed for hardware reconfiguration here.
      Also mark add a comment to that code marking it as
      a workaround.
      
      Finally, remove a pointless aggregation disabling
      loop when an interface is stopped, directly after
      that we remove all stations from it which will also
      disable all aggregation sessions that may still be
      active, and does so in a race-free way unlike the
      current loop that doesn't block new sessions.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2a419056
    • Johannes Berg's avatar
      cfg80211/mac80211: allow action frame TX/RX in IBSS · 9d38d85d
      Johannes Berg authored
      When in IBSS mode, currently action frame TX and RX
      cannot be used. Allow using it to talk to any peer,
      or for public action frames. Also, while at it,
      restructure the code in mac80211 to make it easier
      to add this for other interface types in the future.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      9d38d85d
  12. 08 Jun, 2010 1 commit
  13. 07 Jun, 2010 1 commit
  14. 04 Jun, 2010 2 commits
    • Johannes Berg's avatar
      mac80211: process station blockack action frames from work · 8b9a4e6e
      Johannes Berg authored
      Processing an association response could take a bit
      of time while we set up the hardware etc. During that
      time, the AP might already send a blockack request.
      If this happens very quickly on a fairly slow machine,
      we can end up processing the blockack request before
      the association processing has finished. Since the
      blockack processing cannot sleep right now, we also
      cannot make it wait in the driver.
      
      As a result, sometimes on slow machines the iwlagn
      driver gets totally confused, and no traffic can pass
      when the aggregation setup was done before the assoc
      setup completed.
      
      I'm working on a proper fix for this, which involves
      queuing all blockack category action frames from a
      work struct, and also allowing the ampdu_action driver
      callback to sleep, which will generally clean up the
      code and make things easier.
      
      However, this is a very involved and complex change.
      To fix the problem at hand in a way that can also be
      backported to stable, I've come up with this patch.
      Here, I simply process all aggregation action frames
      from the managed interface skb queue, which means
      their processing will be serialized with processing
      the association response, thereby fixing the problem.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      8b9a4e6e
    • John W. Linville's avatar
  15. 03 Jun, 2010 1 commit
  16. 02 Jun, 2010 2 commits
  17. 12 May, 2010 2 commits
  18. 10 May, 2010 1 commit
    • Mark Gross's avatar
      PM QOS update · ed77134b
      Mark Gross authored
      This patch changes the string based list management to a handle base
      implementation to help with the hot path use of pm-qos, it also renames
      much of the API to use "request" as opposed to "requirement" that was
      used in the initial implementation.  I did this because request more
      accurately represents what it actually does.
      
      Also, I added a string based ABI for users wanting to use a string
      interface.  So if the user writes 0xDDDDDDDD formatted hex it will be
      accepted by the interface.  (someone asked me for it and I don't think
      it hurts anything.)
      
      This patch updates some documentation input I got from Randy.
      Signed-off-by: default avatarmarkgross <mgross@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      ed77134b
  19. 07 May, 2010 2 commits
    • Johannes Berg's avatar
      mac80211: improve HT channel handling · 0aaffa9b
      Johannes Berg authored
      Currently, when one interface switches HT mode,
      all others will follow along. This is clearly
      undesirable, since the new one might switch to
      no-HT while another one is operating in HT.
      
      Address this issue by keeping track of the HT
      mode per interface, and allowing only changes
      that are compatible, i.e. switching into HT40+
      is not possible when another interface is in
      HT40-, in that case the second one needs to
      fall back to HT20.
      
      Also, to allow drivers to know what's going on,
      store the per-interface HT mode (channel type)
      in the virtual interface's bss_conf.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0aaffa9b
    • Reinette Chatre's avatar
      mac80211: remove association work when processing deauth request · 79733a86
      Reinette Chatre authored
      In https://bugzilla.kernel.org/show_bug.cgi?id=15794 a user encountered the
      following:
      
      [18967.469098] wlan0: authenticated
      [18967.472527] wlan0: associate with 00:1c:10:b8:e3:ea (try 1)
      [18967.472585] wlan0: deauthenticating from 00:1c:10:b8:e3:ea by local choice (reason=3)
      [18967.672057] wlan0: associate with 00:1c:10:b8:e3:ea (try 2)
      [18967.872357] wlan0: associate with 00:1c:10:b8:e3:ea (try 3)
      [18968.072960] wlan0: association with 00:1c:10:b8:e3:ea timed out
      [18968.076890] ------------[ cut here ]------------
      [18968.076898] WARNING: at net/wireless/mlme.c:341 cfg80211_send_assoc_timeout+0xa8/0x140()
      [18968.076900] Hardware name: GX628
      [18968.076924] Pid: 1408, comm: phy0 Not tainted 2.6.34-rc4-00082-g250541fc-dirty #3
      [18968.076926] Call Trace:
      [18968.076931]  [<ffffffff8103459e>] ?  warn_slowpath_common+0x6e/0xb0
      [18968.076934]  [<ffffffff8157c2d8>] ?  cfg80211_send_assoc_timeout+0xa8/0x140
      [18968.076937]  [<ffffffff8103ff8b>] ? mod_timer+0x10b/0x180
      [18968.076940]  [<ffffffff8158f0fc>] ?  ieee80211_assoc_done+0xbc/0xc0
      [18968.076943]  [<ffffffff81590d53>] ?  ieee80211_work_work+0x553/0x11c0
      [18968.076945]  [<ffffffff8102d931>] ? finish_task_switch+0x41/0xb0
      [18968.076948]  [<ffffffff81590800>] ?  ieee80211_work_work+0x0/0x11c0
      [18968.076951]  [<ffffffff810476fb>] ? worker_thread+0x13b/0x210
      [18968.076954]  [<ffffffff8104b6b0>] ?  autoremove_wake_function+0x0/0x30
      [18968.076956]  [<ffffffff810475c0>] ? worker_thread+0x0/0x210
      [18968.076959]  [<ffffffff8104b21e>] ? kthread+0x8e/0xa0
      [18968.076962]  [<ffffffff810031f4>] ?  kernel_thread_helper+0x4/0x10
      [18968.076964]  [<ffffffff8104b190>] ? kthread+0x0/0xa0
      [18968.076966]  [<ffffffff810031f0>] ?  kernel_thread_helper+0x0/0x10
      [18968.076968] ---[ end trace 8aa6265f4b1adfe0 ]---
      
      As explained by Johannes Berg <johannes@sipsolutions.net>:
      
      We authenticate successfully, and then userspace requests association.
      Then we start that process, but the AP doesn't respond. While we're
      still waiting for an AP response, userspace asks for a deauth. We do
      the deauth, but don't abort the association work. Then once the
      association work times out we tell cfg80211, but it no longer wants
      to know since for all it is concerned we accepted the deauth that
      also kills the association attempt.
      
      Fix this by, upon receipt of deauth request, removing the association work
      and continuing to send the deauth.
      
      Unfortunately the user reporting the issue is not able to reproduce this
      problem anymore and cannot verify this fix. This seems like a well understood
      issue though and I thus present the patch.
      Bug-identified-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      79733a86
  20. 27 Apr, 2010 1 commit