1. 11 Feb, 2013 4 commits
  2. 04 Feb, 2013 3 commits
  3. 31 Jan, 2013 3 commits
    • Johannes Berg's avatar
      mac80211: start auth/assoc timeout on frame status · 1672c0e3
      Johannes Berg authored
      When sending authentication/association frames they
      might take a bit of time to go out because we may
      have to synchronise with the AP, in particular in
      the case where it's really a P2P GO. In this case
      the 200ms fixed timeout could potentially be too
      short if the beacon interval is relatively large.
      
      For drivers that report TX status we can do better.
      Instead of starting the timeout directly, start it
      only when the frame status arrives. Since then the
      frame was out on the air, we can wait shorter (the
      typical response time is supposed to be 30ms, wait
      100ms.) Also, if the frame failed to be transmitted
      try again right away instead of waiting.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      1672c0e3
    • Emmanuel Grumbach's avatar
      mac80211: inform the driver about update of dtim_period · c65dd147
      Emmanuel Grumbach authored
      Currently, when the driver requires the DTIM period,
      mac80211 will wait to hear a beacon before association.
      This behavior is suboptimal since some drivers may be
      able to deal with knowing the DTIM period after the
      association, if they get it at all.
      
      To address this, notify the drivers with bss_info_changed
      with the new BSS_CHANGED_DTIM_PERIOD flag when the DTIM
      becomes known. This might be when changing to associated,
      or later when the entire association was done with only
      probe response information.
      
      Rename the hardware flag for the current behaviour to
      IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC to more accurately
      reflect its behaviour. IEEE80211_HW_NEED_DTIM_PERIOD is
      no longer accurate as all drivers get the DTIM period
      now, just not before association.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      c65dd147
    • Johannes Berg's avatar
      mac80211: remove assoc data "sent_assoc" · fdcb7869
      Johannes Berg authored
      The field is never used, so remove it.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fdcb7869
  4. 24 Jan, 2013 3 commits
    • Johannes Berg's avatar
      mac80211: remove redundant check · 782d2673
      Johannes Berg authored
      There's no need to have two checks for "associated"
      in ieee80211_sta_restart(), make the first one locked
      to not race (unlikely at this point during resume)
      and remove the second check.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      782d2673
    • Johannes Berg's avatar
      mac80211: fix aggregation state with current drivers · 8147dc7f
      Johannes Berg authored
      For drivers that don't actually flush their queues when
      aggregation stop with the IEEE80211_AMPDU_TX_STOP_FLUSH
      or IEEE80211_AMPDU_TX_STOP_FLUSH_CONT reasons is done,
      like iwlwifi or iwlegacy, mac80211 can then transmit on
      a TID that the driver still considers busy. This happens
      in the following way:
      
       - IEEE80211_AMPDU_TX_STOP_FLUSH requested
       - driver marks TID as emptying
       - mac80211 removes tid_tx data, this can copy packets
         to the TX pending queues and also let new packets
         through to the driver
       - driver gets unexpected TX as it wasn't completely
         converted to the new API
      
      In iwlwifi, this lead to the following warning:
      
      WARNING: at drivers/net/wireless/iwlwifi/dvm/tx.c:442 iwlagn_tx_skb+0xc47/0xce0
      Tx while agg.state = 4
      Modules linked in: [...]
      Pid: 0, comm: kworker/0:0 Tainted: G        W   3.1.0 #1
      Call Trace:
       [<c1046e42>] warn_slowpath_common+0x72/0xa0
       [<c1046f13>] warn_slowpath_fmt+0x33/0x40
       [<fddffa17>] iwlagn_tx_skb+0xc47/0xce0 [iwldvm]
       [<fddfcaa3>] iwlagn_mac_tx+0x23/0x40 [iwldvm]
       [<fd8c98b6>] __ieee80211_tx+0xf6/0x3c0 [mac80211]
       [<fd8cbe00>] ieee80211_tx+0xd0/0x100 [mac80211]
       [<fd8cc176>] ieee80211_xmit+0x96/0xe0 [mac80211]
       [<fd8cc578>] ieee80211_subif_start_xmit+0x348/0xc80 [mac80211]
       [<c1445207>] dev_hard_start_xmit+0x337/0x6d0
       [<c145eee9>] sch_direct_xmit+0xa9/0x210
       [<c14462c0>] dev_queue_xmit+0x1b0/0x8e0
      
      Fortunately, solving this problem is easy as the station
      is being destroyed, so such transmit packets can only
      happen due to races. Instead of trying to close the race
      just let the race not reach the drivers by making two
      changes:
       1) remove the explicit aggregation session teardown in
          the managed mode code, the same thing will be done
          when the station is removed, in __sta_info_destroy.
       2) When aggregation stop with AGG_STOP_DESTROY_STA is
          requested, leave the tid_tx data around as stopped.
          It will be cleared and freed in cleanup_single_sta
          later, but until then any racy packets will be put
          onto the tid_tx pending queue instead of transmitted
          which is fine since the station is being removed.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8147dc7f
    • Emmanuel Grumbach's avatar
      mac80211: provide the vif in rssi_callback · 887da917
      Emmanuel Grumbach authored
      Since drivers can support several BSS / P2P Client
      interfaces, the rssi callback needs to inform the driver
      about the interface teh rssi event relates to.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      887da917
  5. 18 Jan, 2013 1 commit
  6. 11 Jan, 2013 1 commit
  7. 03 Jan, 2013 6 commits
  8. 10 Dec, 2012 1 commit
  9. 03 Dec, 2012 1 commit
  10. 30 Nov, 2012 1 commit
    • Johannes Berg's avatar
      cfg80211: fix BSS struct IE access races · 9caf0364
      Johannes Berg authored
      When a BSS struct is updated, the IEs are currently
      overwritten or freed. This can lead to races if some
      other CPU is accessing the BSS struct and using the
      IEs concurrently.
      
      Fix this by always allocating the IEs in a new struct
      that holds the data and length and protecting access
      to this new struct with RCU.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      9caf0364
  11. 27 Nov, 2012 1 commit
  12. 26 Nov, 2012 2 commits
    • Johannes Berg's avatar
      mac80211: convert to channel definition struct · 4bf88530
      Johannes Berg authored
      Convert mac80211 (and where necessary, some drivers a
      little bit) to the new channel definition struct.
      
      This will allow extending mac80211 for VHT, which is
      currently restricted to channel contexts since there
      are no drivers using that which makes it easier. As
      I also don't care about VHT for drivers not using the
      channel context API, I won't convert the previous API
      to VHT support.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      4bf88530
    • Johannes Berg's avatar
      mac80211: fix managed mode channel flags handling · 028e8da0
      Johannes Berg authored
      If ieee80211_prep_channel() decides that HT should be
      disabled (because the HT IEs from the AP were invalid)
      it will set the IEEE80211_STA_DISABLE_HT to not send
      HT capabilities to the AP when associating. If this
      happens during authentication, the flag will be lost
      and we send HT frames, even if the channel config was
      set up for non-HT. This can lead to issues.
      
      Fix this by always resetting the ifmgd flags to zero
      when the channel context is released so that the flag
      resetting in ieee80211_mgd_assoc() isn't necessary.
      
      To make the code a bit easier move the call to release
      the channel in ieee80211_set_disassoc() to the end of
      the function together with the flag resetting (which
      needs to be at the end to avoid timers setting flags.)
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      028e8da0
  13. 23 Nov, 2012 3 commits
    • Johannes Berg's avatar
      mac80211: disable HT advertising unless AP supports it · 03ae834f
      Johannes Berg authored
      If the AP doesn't support HT, or more importantly if
      it does but we have to disable it because its IEs are
      broken, don't advertise HT support in our association
      request. Otherwise, we configure our channel to be a
      20 MHz non-HT channel but the AP might still think we
      support HT, or even 40 MHz.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      03ae834f
    • Johannes Berg's avatar
      mac80211: rename IEEE80211_STA_DISABLE_11N to HT · a8243b72
      Johannes Berg authored
      Since the 11n spec amendment was rolled into the
      2012 version, "11n" no longer makes sense. Use
      "HT" instead.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      a8243b72
    • Johannes Berg's avatar
      mac80211: fix RX chains configuration · 76c5fa0f
      Johannes Berg authored
      If the driver doesn't support 40 MHz channels, then
      mac80211 erroneously sets number of RX chains to one
      although the number of chains is independent of the
      support for 40 MHz channels.
      
      Fix this by checking the 40 MHz support only for the
      code that sets the 40 MHz channel not the complete
      HT code block.
      
      This also means the HT20 channel type will always be
      set in the changed code block so there's no need to
      set it in case we override the AP due to invalid IEs
      in the probe response/beacon.
      
      The indentation is a bit quirky, but I'm rewriting
      this code for VHT support so this will change again
      very soon.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      76c5fa0f
  14. 06 Nov, 2012 1 commit
  15. 05 Nov, 2012 1 commit
    • Johannes Berg's avatar
      mac80211: send deauth only with channel context · 86552017
      Johannes Berg authored
      When userspace asks to deauthenticate and we're just
      authenticated (or still authenticating) send a deauth
      frame instead of deleting the auth request.
      
      On the other hand, if we've just disassociated and
      therefore deleted all our state already, drop the
      deauth request because we no longer have a channel
      context to send it on.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      86552017
  16. 30 Oct, 2012 1 commit
    • Johannes Berg's avatar
      mac80211: handle TX power per virtual interface · 1ea6f9c0
      Johannes Berg authored
      Even before channel contexts/multi-channel, having a
      single global TX power limit was already problematic,
      in particular if two managed interfaces connected to
      two APs with different power constraints. The channel
      context introduction completely broke this though and
      in fact I had disabled TX power configuration there
      for drivers using channel contexts.
      
      Change everything to track TX power per interface so
      that different user settings and different channel
      maxima are treated correctly. Also continue tracking
      the global TX power though for compatibility with
      applications that attempt to configure the wiphy's
      TX power globally.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      1ea6f9c0
  17. 25 Oct, 2012 1 commit
  18. 18 Oct, 2012 1 commit
  19. 17 Oct, 2012 5 commits