Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 16 3月, 2012 1 次提交
  3. 14 3月, 2012 1 次提交
    • P
      mac80211: Don't let regulatory make us deaf · 3117bbdb
      由 Paul Stewart 提交于 
      When regulatory information changes our HT behavior (e.g,
when we get a country code from the AP we have just associated
with), we should use this information to change the power with
which we transmit, and what channels we transmit.  Sometimes
the channel parameters we derive from regulatory information
contradicts the parameters we used in association.  For example,
we could have associated specifying HT40, but the regulatory
rules we apply may forbid HT40 operation.

In the situation above, we should reconfigure ourselves to
transmit in HT20 only, however it makes no sense for us to
disable receive in HT40, since if we associated with these
parameters, the AP has every reason to expect we can and
will receive packets this way.  The code in mac80211 does
not have the capability of sending the appropriate action
frames to signal a change in HT behaviour so the AP has
no clue we can no longer receive frames encoded this way.
In some broken AP implementations, this can leave us
effectively deaf if the AP never retries in lower HT rates.

This change breaks up the channel_type parameter in the
ieee80211_enable_ht function into a separate receive and
transmit part.  It honors the channel flags set by regulatory
in order to configure the rate control algorithm, but uses
the capability flags to configure the channel on the radio,
since these were used in association to set the AP's transmit
rate.
Signed-off-by: NPaul Stewart <pstew@chromium.org>
Cc: Sam Leffler <sleffler@chromium.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Reviewed-by: NLuis R Rodriguez <mcgrof@frijolero.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3117bbdb
  5. 13 3月, 2012 2 次提交
  7. 08 3月, 2012 1 次提交
    • P
      mac80211: Filter duplicate IE ids · fcff4f10
      由 Paul Stewart 提交于 
      mac80211 is lenient with respect to reception of corrupted beacons.
Even if the frame is corrupted as a whole, the available IE elements
are still passed back and accepted, sometimes replacing legitimate
data.  It is unknown to what extent this "feature" is made use of,
but it is clear that in some cases, this is detrimental.  One such
case is reported in http://crosbug.com/26832 where an AP corrupts
its beacons but not its probe responses.

One approach would be to completely reject frames with invaid data
(for example, if the last tag extends beyond the end of the enclosing
PDU).  The enclosed approach is much more conservative: we simply
prevent later IEs from overwriting the state from previous ones.
This approach hopes that there might be some salient data in the
IE stream before the corruption, and seeks to at least prevent that
data from being overwritten.  This approach will fix the case above.

Further, we flag element structures that contain data we think might
be corrupted, so that as we fill the mac80211 BSS structure, we try
not to replace data from an un-corrupted probe response with that
of a corrupted beacon, for example.

Short of any statistics gathering in the various forms of AP breakage,
it's not possible to ascertain the side effects of more stringent
discarding of data.
Signed-off-by: NPaul Stewart <pstew@chromium.org>
Cc: Sam Leffler <sleffler@chromium.org>
Cc: Eliad Peller <eliad@wizery.com>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fcff4f10
  9. 06 3月, 2012 2 次提交
  11. 01 3月, 2012 1 次提交
  13. 28 2月, 2012 2 次提交
  15. 23 2月, 2012 1 次提交
  17. 07 2月, 2012 2 次提交
  19. 31 1月, 2012 1 次提交
  21. 25 1月, 2012 1 次提交
  23. 05 1月, 2012 1 次提交
  25. 16 12月, 2011 4 次提交
  27. 07 12月, 2011 1 次提交
  29. 01 12月, 2011 1 次提交
  31. 29 11月, 2011 3 次提交
  33. 22 11月, 2011 3 次提交
  35. 12 11月, 2011 2 次提交
  37. 10 11月, 2011 3 次提交
  39. 09 11月, 2011 1 次提交
  41. 03 11月, 2011 1 次提交
  43. 15 10月, 2011 1 次提交
    • H
      mac80211: Build TX radiotap header dynamically · a2fe8166
      由 Helmut Schaa 提交于 
      Get rid of the ieee80211_tx_status_rtap_hdr struct and instead build the
rtap header dynamically. This makes it easier to extend the rtap header
generation in the future.

Add ieee80211_tx_radiotap_len to calculate the expected size of the
rtap header before generating it. Since we can't check if the rtap
header fits into the requested headroom during compile time anymore
add a WARN_ON_ONCE.

Also move the actual rtap header generation into its own function.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a2fe8166
  45. 12 10月, 2011 3 次提交
  47. 01 10月, 2011 1 次提交
    • J
      mac80211: allow out-of-band EOSP notification · 37fbd908
      由 Johannes Berg 提交于 
      iwlwifi has a separate EOSP notification from
the device, and to make use of that properly
it needs to be passed to mac80211. To be able
to mix with tx_status_irqsafe and rx_irqsafe
it also needs to be an "_irqsafe" version in
the sense that it goes through the tasklet,
the actual flag clearing would be IRQ-safe
but doing it directly would cause reordering
issues.

This is needed in the case of a P2P GO going
into an absence period without transmitting
any frames that should be driver-released as
in this case there's no other way to inform
mac80211 that the service period ended. Note
that for drivers that don't use the _irqsafe
functions another version of this function
will be required.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      37fbd908