1. 07 2月, 2012 1 次提交
    • J
      mac80211: redesign auth/assoc · 66e67e41
      Johannes Berg 提交于
      This is the second part of the auth/assoc redesign,
      the mac80211 part. This moves the auth/assoc code
      out of the work abstraction and into the MLME, so
      that we don't flip channels all the time etc.
      
      The only downside is that when we are associated,
      we need to drop the association in order to create
      a connection to another AP, but for most drivers
      this is actually desirable and the ability to do
      was never used by any applications. If we want to
      implement resource reservation with FT-OTA, we'd
      probably best do it with explicit R-O-C in wpa_s.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      66e67e41
  2. 29 11月, 2011 1 次提交
  3. 03 6月, 2010 1 次提交
  4. 08 5月, 2010 1 次提交
    • J
      cfg80211/mac80211: better channel handling · f444de05
      Johannes Berg 提交于
      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: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f444de05
  5. 29 12月, 2009 2 次提交
  6. 19 11月, 2009 1 次提交
  7. 30 7月, 2009 1 次提交
  8. 25 7月, 2009 1 次提交
  9. 28 2月, 2009 1 次提交
    • J
      mac80211: split IBSS/managed code · 46900298
      Johannes Berg 提交于
      This patch splits out the ibss code and data from managed (station) mode.
      The reason to do this is to better separate the state machines, and have
      the code be contained better so it gets easier to determine what exactly
      a given change will affect, that in turn makes it easier to understand.
      
      This is quite some churn, especially because I split sdata->u.sta into
      sdata->u.mgd and sdata->u.ibss, but I think it's easier to maintain that
      way. I've also shuffled around some code -- null function sending is only
      applicable to managed interfaces so put that into that file, some other
      functions are needed from various places so put them into util, and also
      rearranged the prototypes in ieee80211_i.h accordingly.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      46900298
  10. 14 2月, 2009 1 次提交
  11. 30 1月, 2009 2 次提交
  12. 13 12月, 2008 1 次提交
  13. 07 10月, 2008 1 次提交
  14. 12 9月, 2008 3 次提交
  15. 18 7月, 2008 1 次提交
  16. 01 7月, 2008 1 次提交
    • A
      build algorithms into the mac80211 module · e5f5e733
      Adrian Bunk 提交于
      The old infrastructure was:
      - the default algorithm is built into mac80211
      - other algorithms get into their own modules
      
      The implementation of this complicated scheme was horrible
      (just look at net/mac80211/Makefile), and anyone adding a new
      algorithm would most likely not get it right at his first attempt.
      
      This patch therefore builds all enabled algorithms into the mac80211
      module.
      
      The user interface for the rate control algorithms changes as follows:
      - first the user can choose which algorithms to enable (currently only
        MAC80211_RC_PID is available)
      - if more than one algorithm is enabled (currently not possible since
        only one algorithm is present) the user then chooses the default one
      
      Note:
      - MAC80211_RC_PID is always enables for CONFIG_EMBEDDED=n
      
      Technical changes:
      - all selected algorithms get into the mac80211 module
      - net/mac80211/Makefile can now become much less complicated
      - support for rc80211_pid_algo.c being modular is no longer required
      - this includes unexporting mesh_plink_broken
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e5f5e733
  17. 22 5月, 2008 1 次提交
  18. 09 4月, 2008 1 次提交
  19. 14 3月, 2008 1 次提交
  20. 07 3月, 2008 1 次提交
  21. 01 3月, 2008 1 次提交
    • J
      cfg80211 API for channels/bitrates, mac80211 and driver conversion · 8318d78a
      Johannes Berg 提交于
      This patch creates new cfg80211 wiphy API for channel and bitrate
      registration and converts mac80211 and drivers to the new API. The
      old mac80211 API is completely ripped out. All drivers (except ath5k)
      are updated to the new API, in many cases I expect that optimisations
      can be done.
      
      Along with the regulatory code I've also ripped out the
      IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED flag, I believe it to be
      unnecessary if the hardware simply gives us whatever channels it wants
      to support and we then enable/disable them as required, which is pretty
      much required for travelling.
      
      Additionally, the patch adds proper "basic" rate handling for STA
      mode interface, AP mode interface will have to have new API added
      to allow userspace to set the basic rate set, currently it'll be
      empty... However, the basic rate handling will need to be moved to
      the BSS conf stuff.
      
      I do expect there to be bugs in this, especially wrt. transmit
      power handling where I'm basically clueless about how it should work.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8318d78a
  22. 29 1月, 2008 4 次提交
  23. 11 11月, 2007 1 次提交
  24. 11 10月, 2007 7 次提交
  25. 18 7月, 2007 1 次提交
    • D
      [PATCH] mac80211: regulatory domain cleanup · fd8bacc9
      Daniel Drake 提交于
      Currently, a function misnamed ieee80211_init_client() is used to handle
      regulatory domain control. It is called from
      ieee80211_register_hwmode(), which typically runs 2 or 3 times
      (802.11a/b/g), but each time it iterates over all the modes.
      
      This patch cleans this up and removes the confusion:
      ieee80211_init_client was effectively renamed to
      ieee80211_set_default_regdomain and is now run on a per-mode basis
      (doesn't have to deal with netdevs). I also moved the regdomain handling
      code into its own file and added some documentation.
      Signed-off-by: NDaniel Drake <dsd@gentoo.org>
      Acked-by: NJiri Benc <jbenc@suse.cz>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fd8bacc9
  26. 06 5月, 2007 2 次提交