18 Jan, 2017

1 commit


11 Jan, 2017

1 commit

  • When an associated station changes its VHT operating mode this
    can/will affect the bandwidth it's using, and consequently we
    must recalculate the minimum bandwidth we need to use. Failure
    to do so can lead to one of two scenarios:
    1) we use a too high bandwidth, this is benign
    2) we use a too narrow bandwidth, causing rate control and
    actual PHY configuration to be out of sync, which can in
    turn cause problems/crashes

    Signed-off-by: Johannes Berg

    Johannes Berg
     

13 Dec, 2016

1 commit

  • Commit b1bce14a7954 (mac80211: update opmode when adding new station)
    refactored ieee80211_vht_handle_opmode into __ieee80211_vht_handle_opmode
    and ieee80211_vht_handle_opmode leaving a set but unused variable
    (sband) in the former. Compiling with W=1 gives the following warning,
    fix it.

    net/mac80211/vht.c: In function ‘__ieee80211_vht_handle_opmode’:
    net/mac80211/vht.c:424:35: warning: variable ‘sband’ set but not used [-Wunused-but-set-variable]

    Remove 'struct ieee80211_local* local' as well, it was only used to
    set sband.

    This is a harmless warning, and is only being fixed to reduce the
    noise with W=1 in the kernel.

    Fixes: b1bce14a7954 ("mac80211: update opmode when adding new station")
    Cc: Marek Kwaczynski
    Cc: Johannes Berg
    Signed-off-by: Kirtika Ruchandani
    Signed-off-by: Johannes Berg

    Kirtika Ruchandani
     

15 Nov, 2016

1 commit

  • This is a workaround for VHT-enabled STAs which break the spec
    and have the VHT-MCS Rx map filled in with value 3 for all eight
    spacial streams, an example is AR9462 in AP mode.

    As per spec, in section 22.1.1 Introduction to the VHT PHY
    A VHT STA shall support at least single spactial stream VHT-MCSs
    0 to 7 (transmit and receive) in all supported channel widths.

    Some devices in STA mode will get firmware assert when trying to
    associate, examples are QCA9377 & QCA6174.

    Packet example of broken VHT Cap IE of AR9462:

    Tag: VHT Capabilities (IEEE Std 802.11ac/D3.1)
    Tag Number: VHT Capabilities (IEEE Std 802.11ac/D3.1) (191)
    Tag length: 12
    VHT Capabilities Info: 0x00000000
    VHT Supported MCS Set
    Rx MCS Map: 0xffff
    .... .... .... ..11 = Rx 1 SS: Not Supported (0x0003)
    .... .... .... 11.. = Rx 2 SS: Not Supported (0x0003)
    .... .... ..11 .... = Rx 3 SS: Not Supported (0x0003)
    .... .... 11.. .... = Rx 4 SS: Not Supported (0x0003)
    .... ..11 .... .... = Rx 5 SS: Not Supported (0x0003)
    .... 11.. .... .... = Rx 6 SS: Not Supported (0x0003)
    ..11 .... .... .... = Rx 7 SS: Not Supported (0x0003)
    11.. .... .... .... = Rx 8 SS: Not Supported (0x0003)
    ...0 0000 0000 0000 = Rx Highest Long GI Data Rate (in Mb/s, 0 = subfield not in use): 0x0000
    Tx MCS Map: 0xffff
    ...0 0000 0000 0000 = Tx Highest Long GI Data Rate (in Mb/s, 0 = subfield not in use): 0x0000

    Signed-off-by: Filip Matusiak
    Signed-off-by: Johannes Berg

    Filip Matusiak
     

12 Apr, 2016

1 commit

  • This enum is already perfectly aliased to enum nl80211_band, and
    the only reason for it is that we get IEEE80211_NUM_BANDS out of
    it. There's no really good reason to not declare the number of
    bands in nl80211 though, so do that and remove the cfg80211 one.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

05 Apr, 2016

1 commit

  • The previous approach simply ignored chandef restrictions when calculating
    the appropriate peer BW for a WIDER_BW peer. This could result in a
    regulatory violation if both peers indicated 80MHz support, but the
    regdomain forbade it.

    Change the approach to setting a WIDER_BW peer's BW. Don't exempt it from
    the chandef width at first. If during TDLS negotiation the chandef width
    is upgraded, update the peer's BW to match.

    Fixes: 0fabfaafec3a ("mac80211: upgrade BW of TDLS peers when possible")
    Signed-off-by: Arik Nemtsov
    Signed-off-by: Emmanuel Grumbach
    Signed-off-by: Johannes Berg

    Arik Nemtsov
     

24 Feb, 2016

4 commits

  • Drivers may need to track which vif is using VHT MU-MIMO.
    Move the flag indicationg the ownership of MU_MIMO to
    ieee80211_vif.

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

    Sara Sharon
     
  • Provide an interface to the lower level driver to set the VHT
    MU-MIMO data. This is needed for example when there is an update
    of the group data during low power state, where the management
    frame will not be passed to the host at all.

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

    Sara Sharon
     
  • The source and destintation addresses in the memcpy arguments
    are flipped. Fix that.

    Fixes: 23a1f8d44c0b("mac80211: process and save VHT MU-MIMO group frame")
    Signed-off-by: Sara Sharon
    Signed-off-by: Emmanuel Grumbach
    Signed-off-by: Johannes Berg

    Sara Sharon
     
  • In VHT, the specification allows to limit the number of
    MSDUs in an A-MSDU in the Extended Capabilities IE. There
    is also a limitation on the byte size in the VHT IE.
    In HT, the only limitation is on the byte size.
    Parse the capabilities from the peer and make them
    available to the driver.

    In HT, there is another limitation when a BA agreement
    is active: the byte size can't be greater than 4095.
    This is not enforced here.

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

    Emmanuel Grumbach
     

14 Jan, 2016

1 commit

  • The Group ID Management frame is an Action frame of
    category VHT. It is transmitted by the AP to assign
    or change the user position of a STA for one or more
    group IDs.
    Process and save the group membership data. Notify
    underlying driver of changes.

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

    Sara Sharon
     

15 Dec, 2015

1 commit


04 Sep, 2015

1 commit

  • Currently if 80MHz channels are not allowed for use, the VHT IE is not
    included in the probe request for an AP. This is not good enough if the
    AP is configured with the wrong regulatory and supports VHT even where
    prohibited or in TDLS scenarios.
    Mark the ifmgd with the DISABLE_VHT flag for the misbehaving-AP case, and
    unset VHT support from the peer-station entry for the TDLS case.

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

    Arik Nemtsov
     

14 Aug, 2015

1 commit


17 Jul, 2015

1 commit

  • Allow a device to specify support for the TDLS wider-bandwidth feature.
    Indicate this support during TDLS setup in the ext-capab IE and set an
    appropriate station flag when our TDLS peer supports it.
    This feature gives TDLS peers the ability to use a wider channel than
    the base width of the BSS. For instance VHT capable TDLS peers connected
    on a 20MHz channel can extend the channel to 80MHz, if regulatory
    considerations allow it.

    Do not cap the bandwidth of such stations by the current BSS channel width
    in mac80211.

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

    Arik Nemtsov
     

03 Mar, 2015

1 commit


17 Dec, 2014

1 commit

  • Commit e1a0c6b ("mac80211: stop toggling IEEE80211_HT_CAP_SUP_WIDTH_20_40")
    mistakenly removed the actual update of sta->sta.bandwidth.

    Refactor ieee80211_sta_cur_vht_bw() into multiple functions
    (calculate caps-bw and chandef-bw separately, and min them
    with cur_max_bandwidth).

    On ht chanwidth action frame set only cur_max_bandwidth
    (according to the sta capabilities) and recalc the sta bw.

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

    Eliad Peller
     

20 Nov, 2014

1 commit


21 Jul, 2014

1 commit

  • TDLS VHT support requires some more information elements during setup.
    While these are not there, mask out the peer's VHT capabilities so that
    VHT rates are not mistakenly used.

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

    Arik Nemtsov
     

09 May, 2014

1 commit

  • There are two (related) issues with this.

    One case, reported by Michal, is related to hostap: it unsets the
    20/40 capability bit for stations that associate when it's in 20
    MHz mode.

    The other case, reported by Eyal, is that some APs like Netgear
    R6300v2 and probably others based on the BCM4360 chipset can be
    configured for doing VHT at 20Mhz. In this case the beacon has
    a VHT IE but the HT cap indicates transmitter only support 20Mhz.

    In both of these cases, we currently avoid VHT and use only HT
    this means we can't use the highest rates (MCS8), so fixing this
    leads to throughput improvements.

    Reported-by: Michal Kazior
    Reported-by: Eyal Shapira
    Signed-off-by: Johannes Berg

    Johannes Berg
     

05 Feb, 2014

1 commit


26 Nov, 2013

1 commit


01 Oct, 2013

1 commit

  • VHT_CAP_BEAMFORMER_ANTENNAS cap is actually defined in the draft as
    VHT_CAP_BEAMFORMEE_STS_MAX, and its size is 3 bits long.

    VHT_CAP_SOUNDING_DIMENSIONS is also 3 bits long.

    Fix the definitions and change the cap masking accordingly.

    Signed-off-by: Eliad Peller
    Signed-off-by: Johannes Berg

    Eliad Peller
     

13 Jun, 2013

1 commit


06 Mar, 2013

2 commits

  • Implement restricting peer VHT capabilities to the device's own
    capabilities. This is useful when a single driver supports more
    than one device and the devices have different capabilities
    (often they will differ in the number of spatial streams), but
    in particular is also necessary for VHT capability overrides to
    work correctly -- otherwise it'd be possible to e.g. advertise,
    due to overrides, that TX-STBC is not supported, but then still
    use it to TX to the AP because it supports RX-STBC.

    Signed-off-by: Johannes Berg

    Johannes Berg
     
  • Support the cfg80211 API to override VHT capabilities
    on association.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

15 Feb, 2013

6 commits

  • Make all the parsed IE pointers const, and propagate
    the change to all the users etc.

    Signed-off-by: Johannes Berg

    Johannes Berg
     
  • In beacons and association response frames an AP may include an
    operating mode notification element to advertise changes in the
    number of spatial streams it can receive. Handle this using the
    existing function that handles the action frame, but only handle
    NSS changes, not bandwidth changes which aren't allowed here.

    Signed-off-by: Johannes Berg

    Johannes Berg
     
  • Handle the operating mode notification action frame.
    When the supported streams or the bandwidth change
    let the driver and rate control algorithm know.

    Signed-off-by: Johannes Berg

    Johannes Berg
     
  • With VHT, a station can change the number of spatial
    streams it can receive on the fly, not unlike spatial
    multiplexing in HT. Prepare for that by tracking the
    maximum number of spatial streams it can receive when
    the connection is established.

    Signed-off-by: Johannes Berg

    Johannes Berg
     
  • For VHT, many more bandwidth changes are possible. As a first
    step, stop toggling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 flag
    in the HT capabilities and instead introduce a bandwidth field
    indicating the currently usable bandwidth to transmit to the
    station. Of course, make all drivers use it.

    To achieve this, make ieee80211_ht_cap_ie_to_sta_ht_cap() get
    the station as an argument, rather than the new capabilities,
    so it can set up the new bandwidth field.

    If the station is a VHT station and VHT bandwidth is in use,
    also set the bandwidth accordingly.

    Doing this allows us to get rid of the supports_40mhz flag as
    the HT capabilities now reflect the true capability instead of
    the current setting.

    While at it, also fix ieee80211_ht_cap_ie_to_sta_ht_cap() to not
    ignore HT cap overrides when MCS TX isn't supported (not that it
    really happens...)

    Signed-off-by: Johannes Berg

    Johannes Berg
     
  • Like with HT, make things a bit simpler in future patches by
    passing the station to ieee80211_vht_cap_ie_to_sta_vht_cap()
    instead of the vht_cap pointer. Also disable VHT here if HT
    isn't supported.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

17 Oct, 2012

1 commit

  • Save the AP's VHT capabilities (in managed
    mode) and make them available to the driver
    in the station information.

    Unlike HT capabilities, they aren't restricted
    to the common capabilities, so drivers must be
    aware of their own capabilities.

    Signed-off-by: Mahesh Palivela
    [fix endian conversion bug ...]
    Signed-off-by: Johannes Berg

    Mahesh Palivela