Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 15 12月, 2014 1 次提交
  3. 27 11月, 2014 1 次提交
  5. 24 11月, 2014 1 次提交
  7. 20 11月, 2014 3 次提交
  9. 10 11月, 2014 2 次提交
  11. 04 11月, 2014 1 次提交
    • J
      mac80211: handle RIC data element in reassociation request · 8ed28747
      由 Johannes Berg 提交于 
      When the RIC data element (RDE) is included in the IEs coming
from userspace for an association request, its handling is
currently broken as any IEs that are contained within it would
be split off from it and inserted again after all the IEs that
mac80211 generates (e.g. HT, VHT.)

To fix this, treat the RIC element specially, and stop after
it only when we find something that doesn't actually belong to
it. This assumes userspace is actually correctly building it,
directly after the fast BSS transition IE and before all the
others like extended capabilities.

This leaves as a potential problem the case where userspace is
building the following IEs:

[RDE] [vendor resource description] [vendor non-resource IE]

In this case, we'd erroneously consider all three IEs to be
part of the RIC data together, and not split them between the
two vendor IEs. Unfortunately, it isn't easily possible to
distinguish vendor IEs, so this isn't easy to fix. Luckily,
this case is rare as normally wpa_supplicant will include an
extended capabilities IE in the IEs, and that certainly will
break the two vendor IEs apart correctly.
Reviewed-by: NEliad Peller <eliad@wizery.com>
Reviewed-by: NBeni Lev <beni.lev@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8ed28747
  13. 29 10月, 2014 2 次提交
  15. 27 10月, 2014 1 次提交
  17. 22 10月, 2014 1 次提交
    • J
      mac80211: add WMM admission control support · 02219b3a
      由 Johannes Berg 提交于 
      Use the currently existing APIs between mac80211 and the low
level driver to implement WMM admission control.

The low level driver needs to report the media time used by
each transmitted packet in ieee80211_tx_status. Based on that
information, mac80211 will modify the QoS parameters of the
admission controlled Access Category when the limit is
reached. Once the original QoS parameters can be restored,
mac80211 will do so.

One issue with this approach is that management frames will
also erroneously be downgraded, but the upside is that the
implementation is simple. In the future, it can be extended
to driver- or device-based implementations that are better.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      02219b3a
  19. 09 10月, 2014 5 次提交
  21. 11 9月, 2014 2 次提交
  23. 08 9月, 2014 2 次提交
    • S
      mac80211: support DTPC IE (from Cisco Client eXtensions) · c8d65917
      由 Steinar H. Gunderson 提交于 
      Linux already supports 802.11h, where the access point can tell the
client to reduce its transmission power. However, 802.11h is only
defined for 5 GHz, where the need for this is much smaller than on
2.4 GHz.

Cisco has their own solution, called DTPC (Dynamic Transmit Power
Control). Cisco APs on a controller sometimes but not always send
802.11h; they always send DTPC, even on 2.4 GHz. This patch adds support
for parsing and honoring the DTPC IE in addition to the 802.11h
element (they do not always contain the same limits, so both must
be honored); the format is not documented, but very simple.

Tested (on top of wireless.git and on 3.16.1) against a Cisco Aironet
1142 joined to a Cisco 2504 WLC, by setting various transmit power
levels for the given access points and observing the results.
The Wireshark 802.11 dissector agrees with the interpretation of the
element, except for negative numbers, which seem to never happen
anyway.
Signed-off-by: NSteinar H. Gunderson <sgunderson@bigfoot.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      c8d65917
    • S
      mac80211: split 802.11h parsing from transmit power policy · 24a4e400
      由 Steinar H. Gunderson 提交于 
      Decouple the logic of parsing the 802.11d and 802.11h IEs from the
part of deciding what to do about the data (messaging, clamping to
0 dBm, doing the actual setting). This paves the way for the next
patch, which introduces more data sources for transmit power limitation.
Signed-off-by: NSteinar H. Gunderson <sgunderson@bigfoot.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      24a4e400
  25. 05 9月, 2014 3 次提交
  27. 26 8月, 2014 1 次提交
  29. 15 8月, 2014 2 次提交
  31. 21 7月, 2014 3 次提交
  33. 26 6月, 2014 1 次提交
  35. 23 6月, 2014 2 次提交
  37. 13 5月, 2014 1 次提交
  39. 07 5月, 2014 1 次提交
  41. 06 5月, 2014 1 次提交
    • M
      mac80211: fix CSA tx queue stopping · 59af6928
      由 Michal Kazior 提交于 
      It was possible for tx queues to be stuck stopped
if AP CSA finalization failed. In that case
neither stop_ap nor do_stop woke the queues up.
This means it was impossible to perform tx at all
until driver was reloaded or a successful CSA was
performed later.

It was possible to solve this in a simpler manner
however this is more robust and future proof
(having multi-vif CSA in mind).

New sdata->csa_block_tx is introduced to keep
track of which interfaces requested tx to be
blocked for CSA. This is required because mac80211
stops all tx queues for that purpose. This means
queues must be awoken only when last tx-blocking
CSA interface is finished.

It is still possible to have tx queues stopped
after CSA failure but as soon as offending
interfaces are stopped from userspace (stop_ap or
ifdown) tx queues are woken up properly.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      59af6928
  43. 25 4月, 2014 2 次提交
  45. 20 3月, 2014 1 次提交
    • E
      cfg80211/mac80211: ignore signal if the frame was heard on wrong channel · 3afc2167
      由 Emmanuel Grumbach 提交于 
      On 2.4Ghz band, the channels overlap since the delta
between different channels is 5Mhz while the width of the
receiver is 20Mhz (at least).

This means that we can hear beacons or probe responses from
adjacent channels. These frames will have a significant
lower RSSI which will feed all kinds of logic with inaccurate
data. An obvious example is the roaming algorithm that will
think our AP is getting weak and will try to move to another
AP.

In order to avoid this, update the signal only if the frame
has been heard on the same channel as the one advertised by
the AP in its DS / HT IEs.
We refrain from updating the values only if the AP is
already in the BSS list so that we will still have a valid
(but inaccurate) value if the AP was heard on an adjacent
channel only.

To achieve this, stop taking the channel from DS / HT IEs
in mac80211. The DS / HT IEs is taken into account to
discard the frame if it was received on a disabled channel.
This can happen due to the same phenomenon: the frame is
sent on channel 12, but heard on channel 11 while channel
12 can be disabled on certain devices. Since this check
is done in cfg80211, stop even checking this in mac80211.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
[remove unused rx_freq variable]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3afc2167