16 Apr, 2013

1 commit

  • VHT introduces multiple IEs that need to be parsed for a
    wide bandwidth channel switch. Two are (currently) needed
    in mac80211:
    * wide bandwidth channel switch element
    * channel switch wrapper element

    The former is contained in the latter for beacons and probe
    responses, but not for the spectrum management action frames
    so the IE parser needs a new argument to differentiate them.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

08 Apr, 2013

1 commit


26 Mar, 2013

1 commit


19 Mar, 2013

1 commit

  • There are a number of situations in which mac80211 only
    really needs to flush queues for one virtual interface,
    and in fact during this frames might be transmitted on
    other virtual interfaces. Calculate and pass a queue
    bitmap to the driver so it knows which queues to flush.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

11 Mar, 2013

1 commit


15 Feb, 2013

1 commit

  • Add command to trigger radar detection in the driver/FW.
    Once radar detection is started it should continuously
    monitor for radars as long as the channel active.
    If radar is detected usermode notified with 'radar
    detected' event.

    Scanning and remain on channel functionality must be disabled
    while doing radar detection/scanning, and vice versa.

    Based on original patch by Victor Goldenshtein

    Signed-off-by: Simon Wunderlich
    Signed-off-by: Johannes Berg

    Simon Wunderlich
     

12 Feb, 2013

4 commits

  • We've got a couple of races when enabling powersave with an AP for
    off-channel operation. The first is fairly simple. If we go off-channel
    before the nullfunc frame to enable PS is transmitted then it may not be
    received by the AP. Add a flush after enabling off-channel PS to prevent
    this from happening.

    The second race is a bit more subtle. If the driver supports QoS and has
    frames queued when the nullfunc frame is queued, those frames may get
    transmitted after the nullfunc frame. If PM is not set then the AP is
    being told that we've exited PS before we go off-channel and may try to
    deliver frames. To prevent this, add a flush after stopping the queues
    but before passing the nullfunc frame to the driver.

    Signed-off-by: Seth Forshee
    Signed-off-by: Johannes Berg

    Seth Forshee
     
  • Scans currently work by stopping the netdev tx queues but leaving the
    mac80211 queues active. This stops the flow of incoming packets while
    still allowing mac80211 to transmit nullfunc and probe request frames to
    facilitate scanning. However, the driver may try to wake the mac80211
    queues while in this state, which will also wake the netdev queues.

    To prevent this, add a new queue stop reason,
    IEEE80211_QUEUE_STOP_REASON_OFFCHANNEL, to be used when stopping the tx
    queues for off-channel operation. This prevents the netdev queues from
    waking when a driver wakes the mac80211 queues.

    This also stops all frames from being transmitted, even those meant to
    be sent off-channel. Add a new tx control flag,
    IEEE80211_TX_CTL_OFFCHAN_TX_OK, which allows frames to be transmitted
    when the queues are stopped only for the off-channel stop reason. Update
    all locations transmitting off-channel frames to use this flag.

    Signed-off-by: Seth Forshee
    Signed-off-by: Johannes Berg

    Seth Forshee
     
  • In order to be able to predict the next DTIM TBTT
    in the driver, add the ability to use timing data
    from beacons only with the new hardware flag
    IEEE80211_HW_TIMING_BEACON_ONLY and the BSS info
    value sync_dtim_count which is only valid if the
    timing data came from a beacon. The data can only
    come from a beacon, and if no beacon was received
    before association it is updated later together
    with the DTIM count notification.

    Signed-off-by: Johannes Berg

    Johannes Berg
     
  • This prepares for using the spinlock instead of krefs
    which is needed in the next patch to track the refs
    of combined BSSes correctly.

    Acked-by: Bing Zhao [mwifiex]
    Signed-off-by: Johannes Berg

    Johannes Berg
     

31 Jan, 2013

4 commits

  • 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: Stanislaw Gruszka
    Signed-off-by: Johannes Berg

    Stanislaw Gruszka
     
  • 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: Johannes Berg

    Johannes Berg
     
  • These pointers/values are never used, remove them.

    Signed-off-by: Johannes Berg

    Johannes Berg
     
  • We track this, but never use it, so we can
    just remove it.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

29 Jan, 2013

1 commit


16 Jan, 2013

1 commit

  • Since:

    commit b23b025fe246f3acc2988eb6d400df34c27cb8ae
    Author: Ben Greear
    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: Stanislaw Gruszka
    Tested-by: Seth Forshee
    Signed-off-by: Johannes Berg

    Stanislaw Gruszka
     

03 Jan, 2013

3 commits

  • The probe response/beacon management frame RX code passes a
    bool parameter to differentiate beacons and probe responses.
    This is useless since we have the frame and can thus use its
    frame control field. Moreover it is buggy since there is one
    call to ieee80211_rx_bss_info with a beacon frame that is
    indicated as a probe response, which is also fixed by using
    the frame control field, so do that.

    Signed-off-by: Emmanuel Grumbach
    Signed-off-by: Johannes Berg

    Emmanuel Grumbach
     
  • When AP's SSID is hidden the BSS can appear several times in
    cfg80211's BSS list: once with a zero-length SSID that comes
    from the beacon, and once for each SSID from probe reponses.

    Since the mac80211 stores its data in ieee80211_bss which
    is embedded into cfg80211_bss, mac80211's data will be
    duplicated too.

    This becomes a problem when a driver needs the dtim_period
    since this data exists only in the beacon's instance in
    cfg80211 bss table which isn't the instance that is used
    when associating.

    Remove the DTIM period from the BSS table and track it
    explicitly to avoid this problem.

    Cc: stable@vger.kernel.org
    Tested-by: Efi Tubul
    Signed-off-by: Emmanuel Grumbach
    Signed-off-by: Johannes Berg

    Johannes Berg
     
  • Do not scan on no-IBSS and disabled channels in IBSS mode. Doing this
    can trigger Microcode errors on iwlwifi and iwlegacy drivers.

    Also rename ieee80211_request_internal_scan() function since it is only
    used in IBSS mode and simplify calling it from ieee80211_sta_find_ibss().

    This patch should address:
    https://bugzilla.redhat.com/show_bug.cgi?id=883414
    https://bugzilla.kernel.org/show_bug.cgi?id=49411

    Reported-by: Jesse Kahtava
    Reported-by: Mikko Rapeli
    Cc: stable@vger.kernel.org
    Signed-off-by: Stanislaw Gruszka
    Signed-off-by: Johannes Berg

    Stanislaw Gruszka
     

12 Dec, 2012

1 commit


11 Dec, 2012

1 commit


07 Dec, 2012

1 commit


30 Nov, 2012

1 commit


27 Nov, 2012

1 commit


23 Nov, 2012

1 commit

  • Currently, mac80211 checks the DS params IE if present and
    uses it for the (primary) BSS channel, instead of the one
    that the frame was received on. This is particularly useful
    in the 2.4 GHz band since a frame is often received on one
    of the adjacent channels due to overlap.

    Move this code to cfg80211 so other drivers also do this.

    Additionally, on 5 GHz, in particular with some (possibly)
    upcoming changes in 802.11ai and duplicate transmissions
    when wider channels are used, something similar happens.
    So if present, also use the (primary) channel information
    contained in the HT operation IE.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

22 Nov, 2012

1 commit


01 Nov, 2012

1 commit

  • In case that there is an unsupported band, the ie will be
    unallocated and the free will crash.

    Cc: stable@vger.kernel.org
    Signed-off-by: David Spinadel
    Reviewed-by: Emmanuel Grumbach
    Signed-off-by: Johannes Berg

    David Spinadel
     

18 Oct, 2012

1 commit

  • Use NL80211_SCAN_FLAG_LOW_PRIORITY flag in mac80211's scan state
    machine to prematurely terminate scan operations if outbound
    traffic collides. This is useful for marking background scans so
    they don't affect throughput.

    Signed-off-by: Sam Leffler
    Signed-off-by: Amitkumar Karwar
    Signed-off-by: Bing Zhao
    [set feature flag only if software scan is used]
    Signed-off-by: Johannes Berg

    Sam Leffler
     

17 Oct, 2012

2 commits

  • Instead of operating on a single channel only,
    use the new channel context infrastructure in
    all mac80211 code.

    This enables drivers that want to use the new
    channel context infrastructure to use multiple
    channels, while nothing should change for all
    the other drivers that don't support it.

    Right now this disables both TX power settings
    and spatial multiplexing powersave. Both need
    to be re-enabled on a channel context basis.

    Additionally, when channel contexts are used
    drop the connection when channel switch is
    received rather than trying to handle it. This
    will have to be improved later.

    [With fixes from Eliad and Emmanuel incorporated]
    Signed-off-by: Eliad Peller
    Signed-off-by: Emmanuel Grumbach
    Signed-off-by: Johannes Berg

    Johannes Berg
     
  • Depending on the driver, channel contexts may be used or
    not. If they are used, the driver must have support for
    hardware scan and remain-on-channel; otherwise the driver
    must not advertise support for multiple channels.

    Also prohibit WDS type interfaces when channel contexts
    are to be used as there's no clear definition of which
    channel they use.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

07 Sep, 2012

1 commit


06 Sep, 2012

2 commits


20 Aug, 2012

2 commits

  • In multi-channel scenarios, the channel that we will
    transmit a probe request on isn't always the current
    channel (which will be NULL anyway) but will instead
    be the channel that the AP is on. Pass the channel
    to the ieee80211_send_probe_req() function so it can
    be used in the different scenarios. The scan code
    continues to pass the current channel, of course.

    Signed-off-by: Johannes Berg

    Johannes Berg
     
  • The optimisation of scanning only on the current
    channel should check the operating channel. Also
    modify it to compare channel pointer rather than
    the frequency.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

30 Jul, 2012

2 commits


24 Jul, 2012

1 commit


21 Jul, 2012

1 commit


12 Jul, 2012

1 commit

  • Some drivers (iwlegacy, iwlwifi and rt2x00) today use the
    bss_conf.last_tsf value. By itself though that value is
    completely worthless since it may be ancient. What really
    is needed is synchronisation between some device time and
    the TSF.

    To clarify this, rename bss_conf.last_tsf to sync_tsf and
    add sync_device_ts which is obtained from rx_status which
    gets a new field device_timestamp for this purpose. This
    is intentionally not using the mactime field since that
    is used for other things and in IBSS is expected to sync
    with the IBSS's TSF which isn't necessarily true for the
    device timestamp.

    Also, since we have the information and it's useful even
    before the connection has been established, give all the
    timing details to the driver before authenticating.

    Reviewed-by: Emmanuel Grumbach
    Signed-off-by: Johannes Berg

    Johannes Berg