1. 11 Feb, 2013 2 commits
    • Johannes Berg's avatar
      mac80211: explicitly copy channels to VLANs where needed · 1f4ac5a6
      Johannes Berg authored
      
      
      Currently the code assigns channel contexts to VLANs
      (for use by the TX/RX code) when the AP master gets
      its channel context assigned. This works fine, but
      in the upcoming radar detection work the VLANs don't
      require a channel context (during radar detection)
      and assigning one to them anyway causes issues with
      locking and also inconsistencies -- a VLAN interface
      that is added before radar detection would get the
      channel context, while one added during it wouldn't.
      
      Fix these issues moving the channel context copying
      to a new explicit operation that will not be used
      in the radar detection code.
      Acked-by: default avatarSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      1f4ac5a6
    • Christian Lamparter's avatar
      mac80211: protect rx-path with spinlock · f9e124fb
      Christian Lamparter authored
      This patch fixes the problem which was discussed in
      "mac80211: Fix PN corruption in case of multiple
      virtual interface" [1].
      
      Amit Shakya reported a serious issue with my patch:
      mac80211: serialize rx path workers" [2]:
      
      In case, ieee80211_rx_handlers processing is going on
      for skbs received on one vif and at the same time, rx
      aggregation reorder timer expires on another vif then
      sta_rx_agg_reorder_timer_expired is invoked and it will
      push skbs into the single queue (local->rx_skb_queue).
      
      ieee80211_rx_handlers in the while loop assumes that
      the skbs are for the same sdata and sta. This assumption
      doesn't hold good in this scenario and the PN gets
      corrupted by PN received in other vif's skb, causing
      traffic to stop due to PN mismatch."
      
      [1] Message-Id: http://mid.gmane.org/201302041844.44436.chunkeey@googlemail.com
      [2] Commit-Id: 24a8fdad
      
      Reported-by: default avatarAmit Shakya <amit.shakya@stericsson.com>
      Signed-off-by: default avatarChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f9e124fb
  2. 04 Feb, 2013 3 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: 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
  3. 31 Jan, 2013 5 commits
  4. 18 Jan, 2013 2 commits
  5. 16 Jan, 2013 1 commit
    • Stanislaw Gruszka's avatar
      mac80211: synchronize scan off/on-channel and PS states · aacde9ee
      Stanislaw Gruszka authored
      Since:
      
      commit b23b025f
      
      
      Author: Ben Greear <greearb@candelatech.com>
      Date:   Fri Feb 4 11:54:17 2011 -0800
      
          mac80211: Optimize scans on current operating channel.
      
      we do not disable PS while going back to operational channel (on
      ieee80211_scan_state_suspend) and deffer that until scan finish.
      But since we are allowed to send frames, we can send a frame to AP
      without PM bit set, so disable PS on AP side. Then when we switch
      to off-channel (in ieee80211_scan_state_resume) we do not enable PS.
      Hence we are off-channel with PS disabled, frames are not buffered
      by AP.
      
      To fix remove offchannel_ps_disable argument and always enable PS when
      going off-channel and disable it when going on-channel, like it was
      before.
      
      Cc: stable@vger.kernel.org # 2.6.39+
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Tested-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      aacde9ee
  6. 03 Jan, 2013 10 commits
  7. 30 Nov, 2012 1 commit
  8. 27 Nov, 2012 1 commit
  9. 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
      cfg80211: remove remain-on-channel channel type · 42d97a59
      Johannes Berg authored
      
      
      As mwifiex (and mac80211 in the software case) are the
      only drivers actually implementing remain-on-channel
      with channel type, userspace can't be relying on it.
      This is the case, as it's used only for P2P operations
      right now.
      
      Rather than adding a flag to tell userspace whether or
      not it can actually rely on it, simplify all the code
      by removing the ability to use different channel types.
      Leave only the validation of the attribute, so that if
      we extend it again later (with the needed capability
      flag), it can't break userspace sending invalid data.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      42d97a59
  10. 23 Nov, 2012 1 commit
  11. 13 Nov, 2012 1 commit
  12. 10 Nov, 2012 1 commit
  13. 06 Nov, 2012 1 commit
  14. 30 Oct, 2012 2 commits
    • Johannes Berg's avatar
      mac80211: use a counter for remain-on-channel cookie · 50febf6a
      Johannes Berg authored
      
      
      Instead of using the pointer which can be re-used
      fairly quickly due to allocator patterns and then
      makes debugging difficult, maintain a counter and
      use its value. Since it's a 64-bit value it can't
      really wrap, but catch that case anyway since it
      most likely points to a bug somewhere.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      50febf6a
    • 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
  15. 19 Oct, 2012 1 commit
    • Marco Porsch's avatar
      mac80211: make client powersave independent of interface type · d012a605
      Marco Porsch authored
      
      
      This patch prepares mac80211 for a later implementation of mesh or
      ad-hoc powersave clients.
      The structures related to powersave (buffer, TIM map, counters) are
      moved from the AP-specific interface structure to a generic structure
      that can be embedded into any interface type.
      The functions related to powersave are prepared to allow easy
      extension with different interface types. For example with:
      
      + } else if (sta->sdata->vif.type == NL80211_IFTYPE_MESH_POINT) {
      +         ps = &sdata->u.mesh.ps;
      
      Some references to the AP's beacon structure are removed where they
      were obviously not used.
      
      The patch compiles without warning and has been briefly tested as AP
      interface with one client in PS mode.
      Signed-off-by: default avatarMarco Porsch <marco.porsch@etit.tu-chemnitz.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      d012a605
  16. 18 Oct, 2012 2 commits
  17. 17 Oct, 2012 4 commits