1. 11 May, 2009 12 commits
    • Johannes Berg's avatar
      mac80211: properly track HT operation_mode · 413ad50a
      Johannes Berg authored
      
      
      When we disassociate, we set the channel to non-HT which
      obviously invalidates any ht_operation_mode setting. But
      when we then associate with the next AP again, we might
      still have the ht_operation_mode from the previous AP
      cached and fail to configure the hardware with the new
      (but unchanged) operation mode. This patch fixes it by
      separately tracking whether our cache is valid.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      413ad50a
    • Johannes Berg's avatar
      mac80211: move HT operation mode BSS info · 9ed6bcce
      Johannes Berg authored
      
      
      There really is no need to have a separate struct for a
      single variable. The fact that it exists is due to the
      code legacy, but we can remove that now. Very simple.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      9ed6bcce
    • Ivo van Doorn's avatar
      rt2x00: Fix chipset detection for rt73usb · 5a994011
      Ivo van Doorn authored
      
      
      The lower 4 bytes of the chipset revision must contain
      a non-zero value. This bug was introduced by
      "rt2x00: Simplify rt2x00_check_rev".
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5a994011
    • Johannes Berg's avatar
      mac80211: improve scan timing · 99c84cb0
      Johannes Berg authored
      
      
      The call to ieee80211_hw_config() is supposed to apply changes
      synchronously, so once it returns the parameters are applied to
      the hardware. Thus, there really is no need to delay the probing
      by the channel switch time again since the channel switch has
      already happened once we get to this code.
      
      Additionally, there is no need to wait for a NAV update (probe
      delay) when the channel is passively scanned. Remove that extra
      time too.
      
      This cuts scanning time from over 7 seconds to under 4 on ar9170,
      which is due to the number of channels scanned and ar9170's switch
      time being advertised as 135ms (my test now indicates it is about
      77ms with the current driver, but the difference might also be due
      to using a different machine with different USB controllers).
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      99c84cb0
    • Jouni Malinen's avatar
      mac80211: MFP - Drop unprotected Action frames prior key setup · f2ca3ea4
      Jouni Malinen authored
      
      
      When management frame protection (IEEE 802.11w) is used, unprotected
      Robust Action frames are not allowed prior to key configuration.
      However, unprotected Deauthentication and Disassociation frames are
      allowed at that point, but not after key configuration.
      
      Make ieee80211_drop_unencrypted() handle the special cases for MFP by
      separating the basic Data frame case from Management frame processing
      and handle the Management frames only if MFP has been negotiated. In
      addition, do not use sdata->drop_unencrypted for Management frames
      since the decision on whether to accept the frame depends on the key
      being configured.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f2ca3ea4
    • Jouni Malinen's avatar
      mac80211: Drop unencrypted frames based on key setup · 0c7c10c7
      Jouni Malinen authored
      
      
      When using nl80211, we do not have a mechanism to set
      sdata->drop_unencrypted. Currently, this breaks code that is supposed
      to drop unencrypted frames when protection is expected since
      ieee80211_rx_h_decrypt() is optimized to not set rx->key when the
      frame is not protected.
      
      This patch modifies ieee80211_rx_h_decrypt() to set rx->key for all
      frames and only skip decryption if the frame is not protected. This
      allows ieee80211_drop_unencrypted() to correctly drop frames even if
      drop_unencrypted is not set.
      
      The changes here are not enough to handle all cases, though. Additional
      patches will be needed to implement proper IEEE 802.1X PAE for station
      mode (currently, this is only used for AP mode) and some additional
      rules are needed for MFP to drop unprotected Robust Action frames prior
      to having PTK and IGTK configured.
      
      In theory, the unprotected frames could and should be dropped in
      ieee80211_rx_h_decrypt(). However, due to the special case with EAPOL
      frames that have to be allowed to be received unprotected even when
      keys are set, it is simpler to only set rx->key and allow the
      ieee80211_frame_allowed() function to handle the actual dropping of
      data frames after 802.11->802.3 header conversion. In addition,
      unprotected robust management frames are dropped before they are
      processed.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0c7c10c7
    • Johannes Berg's avatar
      iwlwifi: make iwl_set_rate static · 782571f4
      Johannes Berg authored
      
      
      It's not needed outside iwl-core.c
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Acked-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      782571f4
    • Johannes Berg's avatar
      cfg80211: fix wext iw_freq parsing · 0b258582
      Johannes Berg authored
      
      
      The function to parse a struct iw_freq has a stupid bug,
      it returns NULL when the channel cannot be found at all,
      but NULL is supposed to mean "auto". Fix this by checking
      the return value of ieee80211_get_channel() and returning
      ERR_PTR(-EINVAL) if it returned NULL (channel not found).
      
      This fixes an issue where you could say (in IBSS mode)
      	iwconfig wlan0 channel 21
      and it would use channel 1 instead because that's the
      first available channel with IBSS allowed (which is what
      the "auto" setting uses).
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0b258582
    • Johannes Berg's avatar
      mac80211: set default QoS values according to spec · aa837e1d
      Johannes Berg authored
      
      
      We've never really cared about the default QoS (WMM) values, but
      we really should if the AP doesn't send any. This patch makes
      mac80211 use the default values according to 802.11-2007, and
      additionally syncs the default values when we disassociate so
      whatever the last AP said gets "unconfigured".
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      aa837e1d
    • Johannes Berg's avatar
      mac80211: fix scan channel race · 58905ca5
      Johannes Berg authored
      
      
      When a software scan starts, it first sets sw_scanning, but
      leaves the scan_channel "unset" (it currently actually gets
      initialised to a default). Now, when something else tries
      to (re)configure the hardware in the window between these two
      events (after sw_scanning = true, but before scan_channel is
      set), the current code switches to the (unset!) scan_channel.
      This causes trouble, especially when switching bands and
      sending frames on the wrong channel.
      
      To work around this, leave scan_channel initialised to NULL
      and use it to determine whether or not a switch to a different
      channel should occur (and also use the same condition to check
      whether to adjust power for scan or not).
      
      Additionally, avoid reconfiguring the hardware completely when
      recalculating idle resulted in no changes, this was the problem
      that originally led us to discover the race condition in the
      first place, which was helpfully bisected by Pavel. This part
      of the patch should not be necessary with the other fixes, but
      not calling the ieee80211_hw_config function when we know it to
      be unnecessary is certainly a correct thing to do.
      
      Unfortunately, this patch cannot and does not fix the race
      condition completely, but due to the way the scan code is
      structured it makes the particular problem Pavel discovered
      (race while changing channel at the same time as transmitting
      frames) go away. To fix it completely, more work especially
      with locking configuration is needed.
      Bisected-by: default avatarPavel Roskin <proski@gnu.org>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      58905ca5
    • Geert Uytterhoeven's avatar
      wireless: WL12XX should depend on GENERIC_HARDIRQS · 02018b39
      Geert Uytterhoeven authored
      
      
      m68k allmodconfig:
      | drivers/net/wireless/wl12xx/main.c: In function 'wl12xx_probe':
      | drivers/net/wireless/wl12xx/main.c:1273: error: implicit declaration of function 'set_irq_type'
      | make[1]: *** [drivers/net/wireless/wl12xx/main.o] Error 1
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: default avatarKalle Valo <kalle.valo@nokia.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      02018b39
    • Jouni Malinen's avatar
      nl80211 : Add support for configuring MFP · dc6382ce
      Jouni Malinen authored
      
      
      NL80211_CMD_ASSOCIATE request must be able to indicate whether
      management frame protection (IEEE 802.11w) is being used. mac80211 was
      able to use MFP in client mode only with WEXT, but the new
      NL80211_ATTR_USE_MFP attribute will allow this to be done with
      nl80211, too.
      
      Since we are currently using nl80211 for MFP only with drivers that
      use user space SME, only MFP disabled and required values are
      used. However, the NL80211_ATTR_USE_MFP attribute is an enum that can
      be extended with MFP optional in the future, if that is needed with
      some drivers (e.g., if the RSN IE is generated by the driver).
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      dc6382ce
  2. 09 May, 2009 7 commits
  3. 08 May, 2009 5 commits
  4. 07 May, 2009 10 commits
  5. 06 May, 2009 6 commits