1. 10 Apr, 2012 8 commits
  2. 09 Apr, 2012 10 commits
  3. 26 Mar, 2012 2 commits
  4. 15 Mar, 2012 3 commits
  5. 13 Mar, 2012 4 commits
    • Paul Stewart's avatar
      mac80211: Don't let regulatory make us deaf · 3117bbdb
      Paul Stewart authored
      
      
      When regulatory information changes our HT behavior (e.g,
      when we get a country code from the AP we have just associated
      with), we should use this information to change the power with
      which we transmit, and what channels we transmit.  Sometimes
      the channel parameters we derive from regulatory information
      contradicts the parameters we used in association.  For example,
      we could have associated specifying HT40, but the regulatory
      rules we apply may forbid HT40 operation.
      
      In the situation above, we should reconfigure ourselves to
      transmit in HT20 only, however it makes no sense for us to
      disable receive in HT40, since if we associated with these
      parameters, the AP has every reason to expect we can and
      will receive packets this way.  The code in mac80211 does
      not have the capability of sending the appropriate action
      frames to signal a change in HT behaviour so the AP has
      no clue we can no longer receive frames encoded this way.
      In some broken AP implementations, this can leave us
      effectively deaf if the AP never retries in lower HT rates.
      
      This change breaks up the channel_type parameter in the
      ieee80211_enable_ht function into a separate receive and
      transmit part.  It honors the channel flags set by regulatory
      in order to configure the rate control algorithm, but uses
      the capability flags to configure the channel on the radio,
      since these were used in association to set the AP's transmit
      rate.
      Signed-off-by: default avatarPaul Stewart <pstew@chromium.org>
      Cc: Sam Leffler <sleffler@chromium.org>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Reviewed-by: default avatarLuis R Rodriguez <mcgrof@frijolero.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3117bbdb
    • Johannes Berg's avatar
      mac80211: rename bss_conf timestamp to last_tsf · e9ac0745
      Johannes Berg authored
      
      
      This value is not really very useful by itself,
      yet some drivers (including iwlwifi until I can
      figure out what it should do) use it. At least
      rename it to "last_tsf" to indicate the meaning
      and add a note that it may be really old.
      
      I suspect the value may become useful combined
      with the rx_status->mactime, but we don't (yet)
      store that value and pass it to the driver.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e9ac0745
    • Johannes Berg's avatar
      mac80211: linearize SKBs as needed for crypto · a8286911
      Johannes Berg authored
      
      
      Not linearizing every SKB will help actually pass
      non-linear SKBs all the way up when on an encrypted
      connection. For now, linearize TKIP completely as
      it is lower performance and I don't quite grok all
      the details.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a8286911
    • Johannes Berg's avatar
      mac80211: move RX WEP weak IV counting · 617bbde8
      Johannes Berg authored
      
      
      This is better done inside the WEP decrypt
      function where it doesn't have to check all
      the conditions any more since they've been
      tested already.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      617bbde8
  6. 12 Mar, 2012 10 commits
  7. 07 Mar, 2012 3 commits
    • Thomas Pedersen's avatar
      mac80211: fix smatch lock errors in mesh · f06c7885
      Thomas Pedersen authored
      
      
      smatch was complaining:
      
      CHECK   net/mac80211/mesh_pathtbl.c
      net/mac80211/mesh_pathtbl.c:562 mesh_path_add() error: double lock
      'bottom_half:'
      net/mac80211/mesh_pathtbl.c:580 mesh_path_add() error: double unlock
      'bottom_half:'
      net/mac80211/mesh_pathtbl.c:589 mesh_path_add() error: double unlock
      'bottom_half:'
      net/mac80211/mesh_pathtbl.c:691 mpp_path_add() error: double lock
      'bottom_half:'
      net/mac80211/mesh_pathtbl.c:707 mpp_path_add() error: double unlock
      'bottom_half:'
      net/mac80211/mesh_pathtbl.c:716 mpp_path_add() error: double unlock
      'bottom_half:'
      net/mac80211/mesh_pathtbl.c:814 mesh_path_flush_by_nexthop() error:
      double lock 'bottom_half:'
      net/mac80211/mesh_pathtbl.c:819 mesh_path_flush_by_nexthop() error:
      double unlock 'bottom_half:'
      net/mac80211/mesh_pathtbl.c:887 mesh_path_del() error: double lock
      'bottom_half:'
      net/mac80211/mesh_pathtbl.c:901 mesh_path_del() error: double unlock
      'bottom_half:'
      
      So don't lock / unlock with _bh() while bottom halves are already
      disabled.
      Reported-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarThomas Pedersen <thomas@cozybit.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f06c7885
    • Ashok Nagarajan's avatar
      mac80211: Fix potential null pointer dereferencing · 3d4f9699
      Ashok Nagarajan authored
      
      
      The patch "{nl,cfg,mac}80211: Implement RSSI threshold for mesh peering"
      has a potential null pointer dereferencing problem. Thanks to Dan Carpenter
      for pointing out. This patch will fix the issue.
      Signed-off-by: default avatarAshok Nagarajan <ashok@cozybit.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3d4f9699
    • Paul Stewart's avatar
      mac80211: Filter duplicate IE ids · fcff4f10
      Paul Stewart authored
      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: default avatarPaul Stewart <pstew@chromium.org>
      Cc: Sam Leffler <sleffler@chromium.org>
      Cc: Eliad Peller <eliad@wizery.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      fcff4f10