1. 01 11月, 2012 1 次提交
  2. 07 9月, 2012 1 次提交
  3. 06 9月, 2012 1 次提交
  4. 20 8月, 2012 2 次提交
  5. 30 7月, 2012 1 次提交
  6. 24 7月, 2012 1 次提交
  7. 12 7月, 2012 5 次提交
    • J
      mac80211: add time synchronisation with BSS for assoc · 8c358bcd
      Johannes Berg 提交于
      Some drivers (iwlegacy, iwlwifi and rt2x00) today use the
      bss_conf.last_tsf value. By itself though that value is
      completely worthless since it may be ancient. What really
      is needed is synchronisation between some device time and
      the TSF.
      
      To clarify this, rename bss_conf.last_tsf to sync_tsf and
      add sync_device_ts which is obtained from rx_status which
      gets a new field device_timestamp for this purpose. This
      is intentionally not using the mactime field since that
      is used for other things and in IBSS is expected to sync
      with the IBSS's TSF which isn't necessarily true for the
      device timestamp.
      
      Also, since we have the information and it's useful even
      before the connection has been established, give all the
      timing details to the driver before authenticating.
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8c358bcd
    • J
      mac80211: redesign scan RX · d48b2968
      Johannes Berg 提交于
      Scan receive is rather inefficient when there are
      multiple virtual interfaces. We iterate all of the
      virtual interfaces and then notify cfg80211 about
      each beacon many times.
      
      Redesign scan RX to happen before everything else.
      Then we can also get rid of IEEE80211_RX_IN_SCAN
      since we don't have to accept frames into the RX
      handlers for scanning or scheduled scanning any
      more. Overall, this simplifies the code.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d48b2968
    • J
      mac80211: track scheduled scan virtual interface · 5260a5b2
      Johannes Berg 提交于
      Instead of tracking whether or not we're in a
      scheduled scan, track the virtual interface
      (sdata) in an RCU-protected pointer to make it
      usable from RX to check the MAC address.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      5260a5b2
    • J
      mac80211: make scan_sdata pointer usable with RCU · e2fd5dbc
      Johannes Berg 提交于
      Making the scan_sdata pointer usable with RCU makes
      it possible to dereference it in the RX path to see
      if a received frame actually matches the interface
      that is scanning. This is just preparations, making
      the pointer __rcu.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e2fd5dbc
    • A
      mac80211: fix invalid band deref building preq IEs · d811b3d5
      Arik Nemtsov 提交于
      The function building probe-request IEs does not validate the band is
      supported before dereferencing it. This can result in a panic when
      all bands are traversed, as done during sched-scan start.
      
      Warn when this happens and return an empty probe request. Also fix
      sched-scan to not waste memory on unsupported bands.
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d811b3d5
  8. 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
  9. 04 6月, 2012 1 次提交
    • J
      net: Remove casts to same type · e3192690
      Joe Perches 提交于
      Adding casts of objects to the same type is unnecessary
      and confusing for a human reader.
      
      For example, this cast:
      
      	int y;
      	int *p = (int *)&y;
      
      I used the coccinelle script below to find and remove these
      unnecessary casts.  I manually removed the conversions this
      script produces of casts with __force and __user.
      
      @@
      type T;
      T *p;
      @@
      
      -	(T *)p
      +	p
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3192690
  10. 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
  11. 24 4月, 2012 1 次提交
  12. 14 4月, 2012 2 次提交
  13. 29 3月, 2012 1 次提交
  14. 08 3月, 2012 1 次提交
    • P
      mac80211: Filter duplicate IE ids · fcff4f10
      Paul Stewart 提交于
      mac80211 is lenient with respect to reception of corrupted beacons.
      Even if the frame is corrupted as a whole, the available IE elements
      are still passed back and accepted, sometimes replacing legitimate
      data.  It is unknown to what extent this "feature" is made use of,
      but it is clear that in some cases, this is detrimental.  One such
      case is reported in http://crosbug.com/26832 where an AP corrupts
      its beacons but not its probe responses.
      
      One approach would be to completely reject frames with invaid data
      (for example, if the last tag extends beyond the end of the enclosing
      PDU).  The enclosed approach is much more conservative: we simply
      prevent later IEs from overwriting the state from previous ones.
      This approach hopes that there might be some salient data in the
      IE stream before the corruption, and seeks to at least prevent that
      data from being overwritten.  This approach will fix the case above.
      
      Further, we flag element structures that contain data we think might
      be corrupted, so that as we fill the mac80211 BSS structure, we try
      not to replace data from an un-corrupted probe response with that
      of a corrupted beacon, for example.
      
      Short of any statistics gathering in the various forms of AP breakage,
      it's not possible to ascertain the side effects of more stringent
      discarding of data.
      Signed-off-by: NPaul Stewart <pstew@chromium.org>
      Cc: Sam Leffler <sleffler@chromium.org>
      Cc: Eliad Peller <eliad@wizery.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fcff4f10
  15. 06 3月, 2012 1 次提交
  16. 05 1月, 2012 1 次提交
  17. 20 12月, 2011 1 次提交
  18. 01 12月, 2011 1 次提交
  19. 12 11月, 2011 1 次提交
  20. 01 11月, 2011 1 次提交
  21. 12 10月, 2011 1 次提交
  22. 28 9月, 2011 1 次提交
  23. 25 8月, 2011 1 次提交
  24. 20 7月, 2011 1 次提交
  25. 08 7月, 2011 1 次提交
  26. 28 6月, 2011 2 次提交
  27. 18 6月, 2011 1 次提交
  28. 28 5月, 2011 1 次提交
  29. 17 5月, 2011 1 次提交
  30. 13 5月, 2011 1 次提交
  31. 12 5月, 2011 1 次提交
  32. 11 5月, 2011 1 次提交
  33. 08 3月, 2011 1 次提交