1. 07 10月, 2010 4 次提交
  2. 06 10月, 2010 17 次提交
  3. 29 9月, 2010 3 次提交
    • J
      mac80211: Fix WMM driver queue configuration · f2176d72
      Juuso Oikarinen 提交于
      The WMM parameter configuration function (ieee80211_sta_wmm_params) only
      configures the WMM parameters to the driver is the wmm_last_param_set
      counter value is changed by the AP.
      
      The wmm_last_param_set is initialized to -1 on association in order to ensure
      the configuration is made to the driver at least once on association, but
      currently this initialization is done *after* the WMM parameter configuration
      function was called.
      
      This leads to unreliability in the driver getting properly configured on first
      association (depending on what counter value the AP happens to use.) When
      disassociating (the wmm default parameters are configured to the driver) and
      then reassociating, due to the above the WMM configuration is not set to the
      driver at all.
      
      On drivers without beacon filtering the problem is corrected by later beacons,
      but on drivers with beacon filtering the WMM will remain permanently incorrectly
      configured.
      
      Fix this by moving the initialization of wmm_last_param_set to -1 before
      ieee80211_sta_wmm_params is called on association.
      Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f2176d72
    • J
      cfg80211: always set IBSS basic rates · 93b05238
      Johannes Berg 提交于
      IBSS started from wireless extensions is currently
      missing basic rate configuration, fix this by moving
      the code to generate the default to the common code
      that gets invoked for both nl80211 and wext.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      93b05238
    • L
      mac80211: fix offchannel assumption upon association · 8d4780eb
      Luis R. Rodriguez 提交于
      Association is dealt with as an atomic offchannel operation,
      we do this because we don't know we are associated until we
      get the associatin response from the AP. When we do get the
      associatin response though we were never clearing the offchannel
      state. This has a few implications, we told drivers we were
      still offchannel, and the first configured TX power for the
      channel does not take into account any power constraints.
      
      For ath9k this meant ANI calibration would not start upon
      association, and we'd have to wait until the first bgscan
      to be triggered. There may be other issues this resolves
      but I'm too lazy to comb the code to check.
      
      Cc: stable@kernel.org
      Cc: Amod Bodas <amod.bodas@atheros.com>
      Cc: Vasanth Thiagarajan <vasanth.thiagarajan@atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8d4780eb
  4. 28 9月, 2010 10 次提交
  5. 25 9月, 2010 4 次提交
  6. 21 9月, 2010 1 次提交
  7. 17 9月, 2010 1 次提交
    • L
      mac80211: send last 3/5 probe requests as unicast · f01a067d
      Luis R. Rodriguez 提交于
      Some buggy APs do not respond to unicast probe requests
      or send unicast probe requests very delayed so in the
      worst case we should try to send broadcast probe requests,
      otherwise we can get disconnected from these APs.
      
      Even if drivers do not have filters to disregard probe
      responses from foreign APs mac80211 will only process
      probe responses from our associated AP for re-arming
      connection monitoring.
      
      We need to do this since the beacon monitor does not
      push back the connection monitor by design so even if we
      are getting beacons from these type of APs our connection
      monitor currently relies heavily on the way the probe
      requests are received on the AP. An example of an AP
      affected by this is the Nexus One, but this has also been
      observed with random APs.
      
      We can probably optimize this later by using null funcs
      instead of probe requests.
      
      For more details refer to:
      
      http://code.google.com/p/chromium-os/issues/detail?id=5715
      
      This patch has fixes for stable kernels [2.6.35+].
      
      Cc: stable@kernel.org
      Cc: Paul Stewart <pstew@google.com>
      Cc: Amod Bodas <amod.bodas@atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f01a067d