1. 18 Jun, 2013 4 commits
  2. 13 Jun, 2013 3 commits
  3. 12 Jun, 2013 1 commit
  4. 11 Jun, 2013 4 commits
  5. 05 Jun, 2013 3 commits
  6. 04 Jun, 2013 3 commits
  7. 03 Jun, 2013 4 commits
  8. 29 May, 2013 2 commits
    • Johannes Berg's avatar
      mac80211: always send multicast on CAB queue · f4d57941
      Johannes Berg authored
      
      
      If the driver advertised support for a CAB queue, then we
      should put all multicast frames there, otherwise sending
      them can be racy with clients going to sleep while we TX
      a frame. To avoid this, always TX multicast frames on the
      multicast queue.
      
      It seems like even drivers not using the queue framework
      might want to do this which would mean also moving the
      IEEE80211_TX_CTL_SEND_AFTER_DTIM flag assignment, but it
      also seems that drivers behave differently here so that
      just moving it wouldn't be a good idea. It'd be better to
      modify those drivers to use the queue framework.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f4d57941
    • Felix Fietkau's avatar
      mac80211: support active monitor interfaces · 31eba5bc
      Felix Fietkau authored
      
      
      Support them only if the driver advertises support for them via
      IEEE80211_HW_SUPPORTS_ACTIVE_MONITOR. Unlike normal monitor interfaces,
      they are added to the driver, along with their MAC address.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      31eba5bc
  9. 24 May, 2013 4 commits
  10. 23 May, 2013 3 commits
    • Johannes Berg's avatar
      mac80211: close AP_VLAN interfaces before unregistering all · 4c8a9d4b
      Johannes Berg authored
      Since Eric's commit efe117ab
      
       ("Speedup ieee80211_remove_interfaces")
      there's a bug in mac80211 when it unregisters with AP_VLAN interfaces
      up. If the AP_VLAN interface was registered after the AP it belongs
      to (which is the typical case) and then we get into this code path,
      unregister_netdevice_many() will crash because it isn't prepared to
      deal with interfaces being closed in the middle of it. Exactly this
      happens though, because we iterate the list, find the AP master this
      AP_VLAN belongs to and dev_close() the dependent VLANs. After this,
      unregister_netdevice_many() won't pick up the fact that the AP_VLAN
      is already down and will do it again, causing a crash.
      
      Cc: stable@vger.kernel.org [2.6.33+]
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      4c8a9d4b
    • Johannes Berg's avatar
      mac80211: assign AP_VLAN hw queues correctly · 5f38a112
      Johannes Berg authored
      
      
      A lot of code in mac80211 assumes that the hw queues are
      set up correctly for all interfaces (except for monitor)
      but this isn't true for AP_VLAN interfaces. Fix this by
      copying the AP master configuration when an AP VLAN is
      brought up, after this the AP interface can't change its
      configuration any more and needs to be brought down to
      change it, which also forces AP_VLAN interfaces down, so
      just copying in open() is sufficient.
      Reported-by: default avatarJouni Malinen <j@w1.fi>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      5f38a112
    • 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
  11. 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
  12. 16 May, 2013 8 commits