1. 15 10月, 2015 1 次提交
  2. 17 7月, 2015 1 次提交
  3. 27 1月, 2015 2 次提交
  4. 04 11月, 2014 1 次提交
    • R
      mac80211: 802.11p OCB mode support · 239281f8
      Rostislav Lisovy 提交于
      This patch adds 802.11p OCB (Outside the Context of a BSS) mode
      support.
      
      When communicating in OCB mode a mandatory wildcard BSSID
      (48 '1' bits) is used.
      
      The EDCA parameters handling function was changed to support
      802.11p specific values.
      
      The insertion of a newly discovered STAs is done in the similar way
      as in the IBSS mode -- through the deferred insertion.
      
      The OCB mode uses a periodic 'housekeeping task' for expiration of
      disconnected STAs (in the similar manner as in the MESH mode).
      
      New Kconfig option for verbose OCB debugging outputs is added.
      Signed-off-by: NRostislav Lisovy <rostislav.lisovy@fel.cvut.cz>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      239281f8
  5. 23 6月, 2014 2 次提交
  6. 05 5月, 2014 1 次提交
  7. 05 2月, 2013 1 次提交
    • M
      mac80211: mesh power save basics · 3f52b7e3
      Marco Porsch 提交于
      Add routines to
      - maintain a PS mode for each peer and a non-peer PS mode
      - indicate own PS mode in transmitted frames
      - track neighbor STAs power modes
      - buffer frames when neighbors are in PS mode
      - add TIM and Awake Window IE to beacons
      - release frames in Mesh Peer Service Periods
      
      Add local_pm to sta_info to represent the link-specific power
      mode at this station towards the remote station. When a peer
      link is established, use the default power mode stored in mesh
      config. Update the PS status if the peering status of a neighbor
      changes.
      Maintain a mesh power mode for non-peer mesh STAs. Set the
      non-peer power mode to active mode during peering. Authenticated
      mesh peering is currently not working when either node is
      configured to be in power save mode.
      
      Indicate the current power mode in transmitted frames. Use QoS
      Nulls to indicate mesh power mode transitions.
      For performance reasons, calls to the function setting the frame
      flags are placed in HWMP routing routines, as there the STA
      pointer is already available.
      
      Add peer_pm to sta_info to represent the peer's link-specific
      power mode towards the local station. Add nonpeer_pm to
      represent the peer's power mode towards all non-peer stations.
      Track power modes based on received frames.
      
      Add the ps_data structure to ieee80211_if_mesh (for TIM map, PS
      neighbor counter and group-addressed frame buffer).
      
      Set WLAN_STA_PS flag for STA in PS mode to use the unicast frame
      buffering routines in the tx path. Update num_sta_ps to buffer
      and release group-addressed frames after DTIM beacons.
      
      Announce the awake window duration in beacons if in light or
      deep sleep mode towards any peer or non-peer. Create a TIM IE
      similarly to AP mode and add it to mesh beacons. Parse received
      Awake Window IEs and check TIM IEs for buffered frames.
      
      Release frames towards peers in mesh Peer Service Periods. Use
      the corresponding trigger frames and monitor the MPSP status.
      Append a QoS Null as trigger frame if neccessary to properly end
      the MPSP. Currently, in HT channels MPSPs behave imperfectly and
      show large delay spikes and frame losses.
      Signed-off-by: NMarco Porsch <marco@cozybit.com>
      Signed-off-by: NIvan Bezyazychnyy <ivan.bezyazychnyy@gmail.com>
      Signed-off-by: NMike Krinkin <krinkin.m.u@gmail.com>
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3f52b7e3
  8. 17 10月, 2012 1 次提交
  9. 24 6月, 2012 2 次提交
    • J
      mac80211: rename driver-trace file · 011ad0e9
      Johannes Berg 提交于
      This file will contain more soon, so
      rename it to just trace.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      011ad0e9
    • 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
  10. 07 6月, 2012 1 次提交
    • J
      mac80211: unify SW/offload remain-on-channel · 2eb278e0
      Johannes Berg 提交于
      Redesign all the off-channel code, getting rid of
      the generic off-channel work concept, replacing
      it with a simple remain-on-channel list.
      
      This fixes a number of small issues with the ROC
      implementation:
       * offloaded remain-on-channel couldn't be queued,
         now we can queue it as well, if needed
       * in iwlwifi (the only user) offloaded ROC is
         mutually exclusive with scanning, use the new
         queue to handle that case -- I expect that it
         will later depend on a HW flag
      
      The bigger issue though is that there's a bad bug
      in the current implementation: if we get a mgmt
      TX request while HW roc is active, and this new
      request has a wait time, we actually schedule a
      software ROC instead since we can't guarantee the
      existing offloaded ROC will still be that long.
      To fix this, the queuing mechanism was needed.
      
      The queuing mechanism for offloaded ROC isn't yet
      optimal, ideally we should add API to have the HW
      extend the ROC if needed. We could add that later
      but for now use a software implementation.
      
      Overall, this unifies the behaviour between the
      offloaded and software-implemented case as much
      as possible.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2eb278e0
  11. 11 4月, 2012 1 次提交
    • J
      mac80211: Implement mesh synchronization framework · dbf498fb
      Javier Cardona 提交于
      This patch adds MBSS extensible synchronization framework (Sec.
      13.13.2 of IEEE Std. 802.11-2012).
      
      The framework is implemented via an ops table which defines the
      following functions:
      
          rx_bcn_presp() - this is called every time a mesh beacon is
      received.
          adjust_tbtt() - this is called immediately before a beacon is about
      to be transmitted.
      
      The default neighbor offset synchronization defined in the standard is
      implemented.  We also provide template functions for vendor specific
      methods.
      
      When neighbor offset synchronization is active (which is the default)
      mesh neighbors in the same MBSS will track timing offsets to each other
      and compensate clock drift.
      
      In our tests we observed that this mesh synchronization implementation
      successfully corrected drifts between stations of ~2PPM while
      introducing a jitter of ~20us.
      
      It is also possible to test this framework on mac80211_hwsim simulated
      phys to see how it behaves under different topologies, over poor links,
      etc.
      Signed-off-by: NMarco Porsch <marco.porsch@s2005.tu-chemnitz.de>
      Signed-off-by: NPavel Zubarev <pavel.zubarev@gmail.com>
      Signed-off-by: NJavier Cardona <javier@cozybit.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      dbf498fb
  12. 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
  13. 29 11月, 2011 1 次提交
  14. 03 6月, 2010 1 次提交
  15. 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
  16. 29 12月, 2009 2 次提交
  17. 19 11月, 2009 1 次提交
  18. 30 7月, 2009 1 次提交
  19. 25 7月, 2009 1 次提交
  20. 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
  21. 14 2月, 2009 1 次提交
  22. 30 1月, 2009 2 次提交
  23. 13 12月, 2008 1 次提交
  24. 07 10月, 2008 1 次提交
  25. 12 9月, 2008 3 次提交
  26. 18 7月, 2008 1 次提交
  27. 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
  28. 22 5月, 2008 1 次提交
  29. 09 4月, 2008 1 次提交
  30. 14 3月, 2008 1 次提交
  31. 07 3月, 2008 1 次提交
  32. 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
  33. 29 1月, 2008 1 次提交
    • J
      mac80211: better rate control algorithm selection · 4b475898
      Johannes Berg 提交于
      This patch changes mac80211's Kconfig/Makefile to:
       * select between the PID and the SIMPLE rate control
         algorithm as default
       * always allow tri-state for the rate control algorithms,
         building those that are selected 'y' into the mac80211
         module (if that is a module, otherwise all into the kernel)
       * force the default rate control algorithm to be built into
         mac80211
      
      It also makes both rate control algorithms proper modules again
      with MODULE_LICENSE etc.
      
      Only if EMBEDDED is the user allowed to select "NONE" as default
      which will cause no algorithm to be selected, this will work
      only when the driver brings one itself (e.g. iwlwifi drivers).
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4b475898