1. 15 Sep, 2008 2 commits
  2. 11 Sep, 2008 26 commits
  3. 08 Sep, 2008 2 commits
    • Emmanuel Grumbach's avatar
      mac80211: Fix rate scale initialization in IBSS · 8e1535d5
      Emmanuel Grumbach authored
      This patch address some IBSS rate issues introduced or not covered
      by "mac80211: eliminate IBSS warning in rate_lowest_index()" and
      "cfg80211 API for channels/bitrates, mac80211 and driver conversion".
      This patch:
      1. Moves addition of IBSS station from
      prepare_for_handlers to ieee80211_rx_bss_info when triggered from beacon
      eliminating bogus supported rates.
      2. Initialize properly supported rates also in IBSS merging
      3. Ensure that mandatory rates are always added into supported
      rates. This is needed in case when station addition is triggered from
      non beacon/probe packet. Some management frames need to be sent
      4. Remove initialization of supported rates from self rates. This path
      was dead code after 6bc37c06bc4 and in general incorrect.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Cc: Vladimir Koutny <vlado@work.ksp.sk>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Tomas Winkler's avatar
      mac80211: Fix low bit rate in IBSS · 9818babc
      Tomas Winkler authored
      This patch fixes regression in iwlwifi IBSS rate scaling caused by patch:
          commit 6bc37c06bc424bcf3f944e6a79e2d5bb537e02ed
          Author: Vladimir Koutny <vlado@work.ksp.sk>
          Date:   Fri Jun 13 16:50:44 2008 +0200
              mac80211: eliminate IBSS warning in rate_lowest_index()
      An IBSS station is added in prepare_for_handlers where the rate scaling was
      initialized only with single rate matching the received packet.
      The correct rate scale information should be updated only in
      ieee80211_rx_bss_info function where beacon is parsed. Because
      of coding error the rate info was left untouched.
      If a beacon has triggered the connection the rate remined 1Mbps.
      This patch fixes this coding error
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Cc: Vladimir Koutny <vlado@work.ksp.sk>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  4. 05 Sep, 2008 1 commit
  5. 29 Aug, 2008 1 commit
  6. 26 Aug, 2008 3 commits
    • John W. Linville's avatar
      mac80211: quiet chatty IBSS merge message · 576fdeae
      John W. Linville authored
      It seems obvious that this #ifndef should be the opposite polarity...
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Jan-Espen Pettersen's avatar
      mac80211: don't send empty extended rates IE · 8ab65b03
      Jan-Espen Pettersen authored
      The association request includes a list of supported data rates.
      802.11b: 4 supported rates.
      802.11g: 12 (8 + 4) supported rates.
      802.11a: 8 supported rates.
      The rates tag of the assoc request has room for only 8 rates. In case of
      802.11g an extended rate tag is appended. However in net/wireless/mlme.c
      an extended (empty) rate tag is also appended if the number of rates is
      exact 8. This empty (length=0) extended rates tag causes some APs to
      deny association with code 18 (unsupported rates). These APs include my
      ZyXEL G-570U, and according to Tomas Winkler som Cisco APs.
      'If count == 8' has been used to check for the need for an extended rates
      tag. But count would also be equal to 8 if the for loop exited because of
      no more supported rates. Therefore a check for count being less than
      rates_len would seem more correct.
      Thanks to:
       * Dan Williams for newbie guidance
       * Tomas Winkler for confirming the problem
      Signed-off-by: default avatarJan-Espen Pettersen <sigsegv@radiotube.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Jouni Malinen's avatar
      mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM · 087d833e
      Jouni Malinen authored
      The previous code was using IWEVCUSTOM to report IEs from AssocReq and
      AssocResp frames into user space. This can easily hit the 256 byte
      limit (IW_CUSTOM_MAX) with APs that include number of vendor IEs in
      AssocResp. This results in the event message not being sent and dmesg
      showing "wlan0 (WE) : Wireless Event too big (366)" type of errors.
      Convert mac80211 to use IWEVASSOCREQIE/IWEVASSOCRESPIE to avoid the
      issue of being unable to send association IEs as wireless events. These
      newer event types use binary encoding and larger maximum size
      (IW_GENERIC_IE_MAX = 1024), so the likelyhood of not being able to send
      the IEs is much smaller than with IWEVCUSTOM. As an extra benefit, the
      code is also quite a bit simpler since there is no need to allocate an
      extra buffer for hex encoding.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  7. 22 Aug, 2008 5 commits