1. 27 May, 2013 3 commits
  2. 23 May, 2013 1 commit
    • Johannes Berg's avatar
      mac80211: fix queue handling crash · 2b436312
      Johannes Berg authored
      The code I added in "mac80211: don't start new netdev queues
      if driver stopped" crashes for monitor and AP VLAN interfaces
      because while they have a netdev, they don't have queues set
      up by the driver.
      
      To fix the crash, exclude these from queue accounting here
      and just start their netdev queues unconditionally.
      
      For monitor, this is the best we can do, as we can redirect
      frames there to any other interface and don't know which one
      that will since it can be different for each frame.
      
      For AP VLAN interfaces, we can do better later and actually
      properly track the queue status. Not doing this is really a
      separate bug though.
      Reported-by: default avatarIlan Peer <ilan.peer@intel.com>
      Reported-by: default avatarJouni Malinen <j@w1.fi>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      2b436312
  3. 17 May, 2013 1 commit
    • Stanislaw Gruszka's avatar
      mac80211: fix direct probe auth · 6211dd12
      Stanislaw Gruszka authored
      We send direct probe to broadcast address, as some APs do not respond to
      unicast PROBE frames when unassociated. Broadcast frames are not acked,
      so we can not use that for trigger MLME state machine, but we need to
      use old timeout mechanism.
      
      This fixes authentication timed out like below:
      
      [ 1024.671974] wlan6: authenticate with 54:e6:fc:98:63:fe
      [ 1024.694125] wlan6: direct probe to 54:e6:fc:98:63:fe (try 1/3)
      [ 1024.695450] wlan6: direct probe to 54:e6:fc:98:63:fe (try 2/3)
      [ 1024.700586] wlan6: send auth to 54:e6:fc:98:63:fe (try 3/3)
      [ 1024.701441] wlan6: authentication with 54:e6:fc:98:63:fe timed out
      
      With fix, we have:
      
      [ 4524.198978] wlan6: authenticate with 54:e6:fc:98:63:fe
      [ 4524.220692] wlan6: direct probe to 54:e6:fc:98:63:fe (try 1/3)
      [ 4524.421784] wlan6: send auth to 54:e6:fc:98:63:fe (try 2/3)
      [ 4524.423272] wlan6: authenticated
      [ 4524.423811] wlan6: associate with 54:e6:fc:98:63:fe (try 1/3)
      [ 4524.427492] wlan6: RX AssocResp from 54:e6:fc:98:63:fe (capab=0x431 status=0 aid=1)
      
      Cc: stable@vger.kernel.org # 3.9
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      6211dd12
  4. 16 May, 2013 6 commits
  5. 22 Apr, 2013 7 commits
  6. 18 Apr, 2013 1 commit
  7. 17 Apr, 2013 3 commits
  8. 16 Apr, 2013 12 commits
  9. 11 Apr, 2013 2 commits
  10. 10 Apr, 2013 4 commits
    • Johannes Berg's avatar
      mac80211: fix cfg80211 interaction on auth/assoc request · 7b119dc0
      Johannes Berg authored
      If authentication (or association with FT) is requested by
      userspace, mac80211 currently doesn't tell cfg80211 that it
      disconnected from the AP. That leaves inconsistent state:
      cfg80211 thinks it's connected while mac80211 thinks it's
      not. Typically this won't last long, as soon as mac80211
      reports the new association to cfg80211 the old one goes
      away. If, however, the new authentication or association
      doesn't succeed, then cfg80211 will forever think the old
      one still exists and will refuse attempts to authenticate
      or associate with the AP it thinks it's connected to.
      
      Anders reported that this leads to it taking a very long
      time to reconnect to a network, or never even succeeding.
      I tested this with an AP hacked to never respond to auth
      frames, and one that works, and with just those two the
      system never recovers because one won't work and cfg80211
      thinks it's connected to the other so refuses connections
      to it.
      
      To fix this, simply make mac80211 tell cfg80211 when it is
      no longer connected to the old AP, while authenticating or
      associating to a new one.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarAnders Kaseorg <andersk@mit.edu>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      7b119dc0
    • Marek Puzyniak's avatar
      mac80211: provide SSID in IBSS mode · 0ca54f6c
      Marek Puzyniak authored
      Some drivers need SSID in AP and IBSS mode. AP SSID is provided
      through BSS_CHANGED_SSID notification. There was no easy way to
      do the same for IBSS. In IBSS mode SSID is known but was not
      stored in BSS configuration. Extend the AP-mode functionality
      to also work in IBSS mode.
      Signed-off-by: default avatarMarek Puzyniak <marek.puzyniak@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      0ca54f6c
    • Johannes Berg's avatar
      mac80211: always advertise STBC/MCSes even if no AP support · a21a4d3e
      Johannes Berg authored
      Advertise STBC capabilities and MCS rates even if the AP
      doesn't support them. This has always been the right thing
      to do, but used to be problematic with some APs. Now WFA
      testing requires this so re-enable it, problematic APs
      would then presumably not pass the test and be fixed.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      a21a4d3e
    • Marek Puzyniak's avatar
      mac80211: clear SSID when stopping AP · 0eabccd9
      Marek Puzyniak authored
      When AP interface is stopped ssid_len in the BSS configuration
      isn't cleared which can confuse drivers when switching modes.
      Set the length to zero when stopping the AP interface.
      Signed-off-by: default avatarMarek Puzyniak <marek.puzyniak@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      0eabccd9