All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

  1. 11 Feb, 2013 11 commits
  2. 05 Feb, 2013 1 commit
  3. 04 Feb, 2013 6 commits
    • Marco Porsch's avatar
      mac80211: mesh power save basics · 3f52b7e3
      Marco Porsch authored
      Add routines to
      - maintain a PS mode for each peer and a non-peer PS mode
      - indicate own PS mode in transmitted frames
      - track neighbor STAs power modes
      - buffer frames when neighbors are in PS mode
      - add TIM and Awake Window IE to beacons
      - release frames in Mesh Peer Service Periods
      
      Add local_pm to sta_info to represent the link-specific power
      mode at this station towards the remote station. When a peer
      link is established, use the default power mode stored in mesh
      config. Update the PS status if the peering status of a neighbor
      changes.
      Maintain a mesh power mode for non-peer mesh STAs. Set the
      non-peer power mode to active mode during peering. Authenticated
      mesh peering is currently not working when either node is
      configured to be in power save mode.
      
      Indicate the current power mode in transmitted frames. Use QoS
      Nulls to indicate mesh power mode transitions.
      For performance reasons, calls to the function setting the frame
      flags are placed in HWMP routing routines, as there the STA
      pointer is already available.
      
      Add peer_pm to sta_info to represent the peer's link-specific
      power mode towards the local station. Add nonpeer_pm to
      represent the peer's power mode towards all non-peer stations.
      Track power modes based on received frames.
      
      Add the ps_data structure to ieee80211_if_mesh (for TIM map, PS
      neighbor counter and group-addressed frame buffer).
      
      Set WLAN_STA_PS flag for STA in PS mode to use the unicast frame
      buffering routines in the tx path. Update num_sta_ps to buffer
      and release group-addressed frames after DTIM beacons.
      
      Announce the awake window duration in beacons if in light or
      deep sleep mode towards any peer or non-peer. Create a TIM IE
      similarly to AP mode and add it to mesh beacons. Parse received
      Awake Window IEs and check TIM IEs for buffered frames.
      
      Release frames towards peers in mesh Peer Service Periods. Use
      the corresponding trigger frames and monitor the MPSP status.
      Append a QoS Null as trigger frame if neccessary to properly end
      the MPSP. Currently, in HT channels MPSPs behave imperfectly and
      show large delay spikes and frame losses.
      Signed-off-by: default avatarMarco Porsch <marco@cozybit.com>
      Signed-off-by: default avatarIvan Bezyazychnyy <ivan.bezyazychnyy@gmail.com>
      Signed-off-by: default avatarMike Krinkin <krinkin.m.u@gmail.com>
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3f52b7e3
    • Johannes Berg's avatar
      mac80211: send deauth if connection was lost during suspend · 6b684db1
      Johannes Berg authored
      If the driver determined the connection was lost or that
      it couldn't securely maintain the connection when coming
      out of WoWLAN, send a deauth frame to the AP to also let
      it know.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      6b684db1
    • Johannes Berg's avatar
      mac80211: allow transmitting deauth with tainted key · e54faf29
      Johannes Berg authored
      When we had a connection for WoWLAN and after resume it
      needed to be disconnected, the previous commit enabled
      sending a deauth frame to the AP. This frame would not
      go through on MFP-enabled networks as the key for it is
      marked tainted before the frame is transmitted.
      
      Allow a tainted key to be used for deauth frames. Worst
      case, we'll use a wrong key because the PTK was rekeyed
      while suspended, but more likely the PTK is still fine
      and the taint flag really only applies to the GTK(s).
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      e54faf29
    • Johannes Berg's avatar
      mac80211: remove unused SSID from BSS · 3146a7da
      Johannes Berg authored
      The ssid/ssid_len fields in the private BSS
      struct are unused, contrary to the comment
      we do look up the SSID in the few cases we
      need it.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3146a7da
    • Johannes Berg's avatar
      mac80211: always allow calling ieee80211_connection_loss() · 682bd38b
      Johannes Berg authored
      With multi-channel, there's a corner case where a driver
      doesn't receive a beacon soon enough to be able to sync
      its timers with the AP. In this case, the only recovery
      (after trying again) is to disconnect from the AP. Allow
      calling ieee80211_connection_loss() for such cases. To
      make that possible, modify the work function to not rely
      on the IEEE80211_HW_CONNECTION_MONITOR flag but use new
      state kept in the interface instead.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      682bd38b
    • Johannes Berg's avatar
      mac80211: send deauth when connection is lost · eef9e54c
      Johannes Berg authored
      If the driver determines the connection is lost,
      send a deauth frame to the AP anyway just in case
      it still considers the connection alive. The frame
      might not go through, but at least we've tried.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      eef9e54c
  4. 31 Jan, 2013 7 commits
    • Stanislaw Gruszka's avatar
      mac80211: improve latency and throughput while software scanning · 3f892b61
      Stanislaw Gruszka authored
      Patch vastly improve latency while scanning. Slight throughput
      improvements were observed as well. Is intended for improve performance
      of voice and video applications, when scan is periodically requested by
      user space (i.e. default NetworkManager behaviour).
      
      Patch remove latency requirement based on PM_QOS_NETWORK_LATENCY,
      this value is 2000 seconds by default (i.e. approximately 0.5 hour !?!).
      
      Also remove listen interval requirement, which based on beaconing and
      depending on BSS parameters. It can make we stay off-channel for a
      second or more.
      
      Instead try to offer the best latency that we could, i.e. be off-channel
      no longer than PASSIVE channel scan time: 125 ms. That mean we will
      scan two ACTIVE channels and go back to on-channel, and one PASSIVE
      channel, and go back to on-channel.
      
      Patch also decrease PASSIVE channel scan time to about 110 ms.
      
      As drawback patch increase overall scan time. On my tests, when scanning
      both 2GHz and 5GHz bands, scanning time increase from 5 seconds up to 10
      seconds. Since that increase happen only when we are associated, I think
      it can be acceptable. If eventually better scan time is needed for
      situations when we lose signal and quickly need to decide to which AP
      roam, additional scan flag or parameter can be introduced.
      
      I tested patch by doing:
      
      while true; do iw dev wlan0 scan; sleep 3; done > /dev/null
      
      and
      
      ping -i0.2 -c 1000 HOST
      
      on remote and local machine, results are as below:
      
      * Ping from local periodically scanning machine to AP:
      Unpatched: rtt min/avg/max/mdev = 0.928/24.946/182.135/36.873 ms
      Patched:   rtt min/avg/max/mdev = 0.928/19.678/150.845/33.130 ms
      
      * Ping from remote machine to periodically scanning machine:
      Unpatched: rtt min/avg/max/mdev = 1.637/120.683/709.139/164.337 ms
      Patched:   rtt min/avg/max/mdev = 1.807/26.893/201.435/40.284 ms
      
      Throughput measured by scp show following results.
      
      * Upload to periodically scanning machine:
      Unpatched: 3.9MB/s   03:15
      Patched:   4.3MB/s   02:58
      
      * Download from periodically scanning machine:
      Unpatched: 5.5MB/s   02:17
      Patched:   6.2MB/s   02:02
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3f892b61
    • 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
    • Johannes Berg's avatar
      mac80211: remove unused mesh data from bss · 0fe20add
      Johannes Berg authored
      These pointers/values are never used, remove them.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      0fe20add
    • Johannes Berg's avatar
      mac80211: remove last_probe_resp from bss · ce9877c0
      Johannes Berg authored
      We track this, but never use it, so we can
      just remove it.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      ce9877c0
    • 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
    • Johannes Berg's avatar
      cfg80211/mac80211: support reporting wakeup reason · cd8f7cb4
      Johannes Berg authored
      When waking up from WoWLAN, it is useful to know
      what triggered the wakeup. Support reporting the
      wakeup reason(s) in cfg80211 (and a pass-through
      in mac80211) to allow userspace to know.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      cd8f7cb4
  5. 29 Jan, 2013 2 commits
  6. 28 Jan, 2013 1 commit
  7. 25 Jan, 2013 1 commit
    • Arnd Bergmann's avatar
      mac80211: avoid a build warning · fe80123d
      Arnd Bergmann authored
      gcc cannot prove that the value of sdata->vif.type does not
      change between the switch() statement and the second
      comparison to NL80211_IFTYPE_AP, causing a harmless
      warning.
      Slightly reordering the code makes the warning go away
      with no functional change.
      
      Without this patch, building ARM at91sam9g45_defconfig with
      gcc-4.6 results in:
      
      net/mac80211/tx.c: In function 'ieee80211_subif_start_xmit':
      net/mac80211/tx.c:1797:22: warning: 'chanctx_conf' may be used uninitialized in this function [-Wuninitialized]
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: linux-wireless@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fe80123d
  8. 24 Jan, 2013 5 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
    • Thomas Pedersen's avatar
      mac80211: support mesh rate updates · f68d776a
      Thomas Pedersen authored
      An existing mesh station entry may change its rate
      capabilities, so call rate_control_rate_update() to notify
      the rate control.
      Signed-off-by: default avatarThomas Pedersen <thomas@cozybit.com>
      [fix compilation]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f68d776a
    • Thomas Pedersen's avatar
      mac80211: clean up mesh sta allocation warning · 296fcba3
      Thomas Pedersen authored
      This refactoring fixes a "scheduling while atomic" warning
      when allocating a mesh station entry while holding the RCU
      read lock. Fix this by creating a new function
      mesh_sta_info_get(), which correctly handles the locking
      and returns under RCU.
      
      Also move some unnecessarily #ifdefed mesh station init
      code from sta_info_alloc() to __mesh_sta_info_alloc().
      Signed-off-by: default avatarThomas Pedersen <thomas@cozybit.com>
      [change code flow to make sparse happy]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      296fcba3
    • 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
  9. 18 Jan, 2013 4 commits
  10. 16 Jan, 2013 2 commits
    • Johannes Berg's avatar
      mac80211: split out chandef tracing macros · 5a32aff3
      Johannes Berg authored
      Some new APIs will require tracing a chandef without
      it being part of a channel context, so separate out
      the tracing macros for that.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      5a32aff3
    • Bob Copeland's avatar
      mac80211: add encrypt headroom to PERR frames · 8680451f
      Bob Copeland authored
      Mesh PERR action frames are robust and thus may be encrypted, so add
      proper head/tailroom to allow this.  Fixes this warning when operating
      a Mesh STA on ath5k:
      
      WARNING: at net/mac80211/wpa.c:427 ccmp_encrypt_skb.isra.5+0x7b/0x1a0 [mac80211]()
      Call Trace:
       [<c011c5e7>] warn_slowpath_common+0x63/0x78
       [<c011c60b>] warn_slowpath_null+0xf/0x13
       [<e090621d>] ccmp_encrypt_skb.isra.5+0x7b/0x1a0 [mac80211]
       [<e090685c>] ieee80211_crypto_ccmp_encrypt+0x1f/0x37 [mac80211]
       [<e0917113>] invoke_tx_handlers+0xcad/0x10bd [mac80211]
       [<e0917665>] ieee80211_tx+0x87/0xb3 [mac80211]
       [<e0918932>] ieee80211_tx_pending+0xcc/0x170 [mac80211]
       [<c0121c43>] tasklet_action+0x3e/0x65
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8680451f