1. 07 Oct, 2010 1 commit
  2. 06 Oct, 2010 2 commits
  3. 05 Oct, 2010 3 commits
  4. 16 Sep, 2010 2 commits
  5. 27 Aug, 2010 3 commits
  6. 25 Aug, 2010 2 commits
  7. 24 Aug, 2010 2 commits
  8. 16 Aug, 2010 2 commits
  9. 27 Jul, 2010 1 commit
    • Jouni Malinen's avatar
      mac80211: Fix key freeing to handle unlinked keys · 32162a4d
      Jouni Malinen authored
      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: default avatarJouni Malinen <j@w1.fi>
      Reviewed-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  10. 26 Jul, 2010 1 commit
  11. 20 Jul, 2010 2 commits
  12. 08 Jul, 2010 1 commit
    • John W. Linville's avatar
      mac80211: remove wep dependency · 3473187d
      John W. Linville authored
      The current mac80211 code assumes that WEP is always available.  If WEP
      fails to initialize, ieee80211_register_hw will always fail.
      In some cases (e.g. FIPS certification), the cryptography used by WEP is
      unavailable.  However, in such cases there is no good reason why CCMP
      encryption (or even no link level encryption) cannot be used.  So, this
      patch removes mac80211's assumption that WEP (and TKIP) will always be
      available for use.
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  13. 29 Jun, 2010 1 commit
  14. 24 Jun, 2010 1 commit
  15. 15 Jun, 2010 1 commit
    • 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>
  16. 14 Jun, 2010 1 commit
  17. 03 Jun, 2010 2 commits
  18. 02 Jun, 2010 1 commit
  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>
    • Johannes Berg's avatar
      cfg80211/mac80211: better channel handling · f444de05
      Johannes Berg authored
      Currently (all tested with hwsim) you can do stupid
      things like setting up an AP on a certain channel,
      then adding another virtual interface and making
      that associate on another channel -- this will make
      the beaconing to move channel but obviously without
      the necessary IEs data update.
      In order to improve this situation, first make the
      configuration APIs (cfg80211 and nl80211) aware of
      multi-channel operation -- we'll eventually need
      that in the future anyway. There's one userland API
      change and one API addition. The API change is that
      now SET_WIPHY must be called with virtual interface
      index rather than only wiphy index in order to take
      effect for that interface -- luckily all current
      users (hostapd) do that. For monitor interfaces, the
      old setting is preserved, but monitors are always
      slaved to other devices anyway so no guarantees.
      The second userland API change is the introduction
      of a per virtual interface SET_CHANNEL command, that
      hostapd should use going forward to make it easier
      to understand what's going on (it can automatically
      detect a kernel with this command).
      Other than mac80211, no existing cfg80211 drivers
      are affected by this change because they only allow
      a single virtual interface.
      mac80211, however, now needs to be aware that the
      channel settings are per interface now, and needs
      to disallow (for now) real multi-channel operation,
      which is another important part of this patch.
      One of the immediate benefits is that you can now
      start hostapd to operate on a hardware that already
      has a connection on another virtual interface, as
      long as you specify the same channel.
      Note that two things are left unhandled (this is an
      improvement -- not a complete fix):
       * different HT/no-HT modes
         currently you could start an HT AP and then
         connect to a non-HT network on the same channel
         which would configure the hardware for no HT;
         that can be fixed fairly easily
       * CSA
         An AP we're connected to on a virtual interface
         might indicate switching channels, and in that
         case we would follow it, regardless of how many
         other interfaces are operating; this requires
         more effort to fix but is pretty rare after all
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  20. 27 Apr, 2010 3 commits
  21. 20 Apr, 2010 1 commit
  22. 31 Mar, 2010 2 commits
  23. 30 Mar, 2010 1 commit
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      The script does the followings.
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      * When the script inserts a new include, it looks at the include
  24. 24 Mar, 2010 1 commit
  25. 15 Feb, 2010 1 commit
    • Jouni Malinen's avatar
      cfg80211/mac80211: allow registering for and sending action frames · 026331c4
      Jouni Malinen authored
      This implements a new command to register for action frames
      that userspace wants to handle instead of the in-kernel
      rejection. It is then responsible for rejecting ones that
      it decided not to handle. There is no unregistration, but
      the socket can be closed for that.
      Frames that are not registered for will not be forwarded
      to userspace and will be rejected by the kernel, the
      cfg80211 API helps implementing that.
      Additionally, this patch adds a new command that allows
      doing action frame transmission from userspace. It can be
      used either to exchange action frames on the current
      operational channel (e.g., with the AP with which we are
      currently associated) or to exchange off-channel Public
      Action frames with the remain-on-channel command.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>