1. 14 6月, 2012 1 次提交
  2. 13 6月, 2012 2 次提交
  3. 11 6月, 2012 2 次提交
  4. 07 6月, 2012 3 次提交
    • 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
    • J
      mac80211: do remain-on-channel while idle · 196ac1c1
      Johannes Berg 提交于
      The IDLE handling in HW off-channel is broken right
      now since we turn off IDLE only when the off-channel
      period already started. Therefore, all drivers that
      use it today (only iwlwifi!) must support off-channel
      while idle, so playing with idle isn't needed at all.
      
      Off-channel in general, since it's no longer used for
      authentication/association, shouldn't affect PS, so
      also remove that logic.
      
      Also document a small caveat for reporting TX status
      from off-channel frames in HW remain-on-channel.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      196ac1c1
    • J
      cfg80211: clarify set_channel APIs · e8c9bd5b
      Johannes Berg 提交于
      Now that we've removed all uses of the set_channel
      API except for the monitor channel and in libertas,
      clarify this. Split the libertas mesh use into a
      new libertas_set_mesh_channel() operation, just to
      keep backward compatibility, and rename the normal
      set_channel() to set_monitor_channel().
      
      Also describe the desired set_monitor_channel()
      semantics more clearly.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e8c9bd5b
  5. 06 6月, 2012 6 次提交
  6. 05 6月, 2012 1 次提交
  7. 10 5月, 2012 1 次提交
    • J
      mac80211: Convert compare_ether_addr to ether_addr_equal · b203ca39
      Joe Perches 提交于
      Use the new bool function ether_addr_equal to add
      some clarity and reduce the likelihood for misuse
      of compare_ether_addr for sorting.
      
      Done via cocci script:
      
      $ cat compare_ether_addr.cocci
      @@
      expression a,b;
      @@
      -	!compare_ether_addr(a, b)
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	compare_ether_addr(a, b)
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!ether_addr_equal(a, b) == 0
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!ether_addr_equal(a, b) != 0
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	ether_addr_equal(a, b) == 0
      +	!ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	ether_addr_equal(a, b) != 0
      +	ether_addr_equal(a, b)
      
      @@
      expression a,b;
      @@
      -	!!ether_addr_equal(a, b)
      +	ether_addr_equal(a, b)
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b203ca39
  8. 09 5月, 2012 4 次提交
  9. 25 4月, 2012 1 次提交
    • F
      mac80211: fix num_mcast_sta counting issues · 7e3ed02c
      Felix Fietkau 提交于
      Moving a STA to an AP VLAN prevents num_mcast_sta from being decremented
      once the STA leaves, because sta->sdata changes. Fix this by checking
      for AP VLANs as well.
      
      Also exclude 4-addr VLAN stations from num_mcast_sta - remote 4-addr
      stations ignore 3-address multicast frames anyway. In a typical bridge
      configuration they receive the same packets as 4-address unicast.
      
      This patch also fixes clearing the sdata->u.vlan.sta pointer when the
      STA is removed from a 4-addr VLAN.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7e3ed02c
  10. 14 4月, 2012 1 次提交
  11. 12 4月, 2012 4 次提交
  12. 11 4月, 2012 3 次提交
  13. 07 3月, 2012 1 次提交
  14. 06 3月, 2012 1 次提交
  15. 01 3月, 2012 1 次提交
  16. 23 2月, 2012 1 次提交
  17. 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
  18. 31 1月, 2012 2 次提交
  19. 28 1月, 2012 2 次提交
  20. 25 1月, 2012 1 次提交
  21. 14 1月, 2012 1 次提交
    • J
      mac80211: fix no-op authorized transitions · 543d1b92
      Johannes Berg 提交于
      When userspace attempts to authorize a station
      that is already authorized, nothing happens as
      you'd expect. Similarly, when it unauthorizes
      a station that is associated, nothing happens.
      
      However, when it unauthorizes a station that
      isn't even associated yet, we erroneously try
      to move the station to associated. This seems
      to happen occasionally as a result of a race
      when wpa_supplicant attempts to unauthorize
      the port in managed mode. Particularly with my
      new patches to keep stations, it can then move
      a station into ASSOCIATED state before we have
      really associated, which is really confusing.
      
      I introduced this bug in
      "mac80211: refactor station state transitions"
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      543d1b92