linux.git/net/mac80211/rate.c, branch v4.0

mac80211: add more missing checks for VHT tx rates

2014-11-28T13:24:23+00:00

Fixes a crash on attempting to calculate the frame duration for a VHT
packet (which needs to be handled by hw/driver instead).

Reported-by: Jouni Malinen 
Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg

mac80211: notify drivers on sta rate table changes

2014-11-19T18:15:50+00:00

This allows drivers with a firmware or chip-based rate lookup table to
use the most recent default rate selection without having to get it from
per-packet data or explicit ieee80211_get_tx_rate calls

Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg

mac80211: skip legacy rate mask handling for VHT rates

2014-11-19T17:46:35+00:00

The rate mask code currently assumes that a rate is legacy if
IEEE80211_TX_RC_MCS is not set. This might be the cause of bogus VHT
rates being reported with minstrel_ht.

Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg

mac80211: fix typo in starting baserate for rts_cts_rate_idx

2014-10-14T09:16:16+00:00

It affects non-(V)HT rates and can lead to selecting an rts_cts rate
that is not a basic rate or way superior to the reference rate (ATM
rates[0] used for the 1st attempt of the protected frame data).

E.g, assuming drivers register growing (bitrate) sorted tables of
ieee80211_rate-s, having :
- rates[0].idx == d'2 and basic_rates == b'10100
will select rts_cts idx b'10011 & ~d'(BIT(2)-1), i.e. 1, likewise
- rates[0].idx == d'2 and basic_rates == b'10001
will select rts_cts idx b'10000
The first is not a basic rate and the second is > rates[0].

Also, wrt severity of the addressed misbehavior, ATM we only have one
rts_cts_rate_idx rather than one per rate table entry, so this idx might
still point to bitrates > rates[1..MAX_RATES].

Fixes: 5253ffb8c9e1 ("mac80211: always pick a basic rate to tx RTS/CTS for pre-HT rates")
Cc: stable@vger.kernel.org
Signed-off-by: Karl Beldan 
Signed-off-by: Johannes Berg

mac80211: remove module handling from rate control ops

2014-02-04T20:48:26+00:00

There's not a single rate control algorithm actually in
a separate module where the module refcount would be
required. Similarly, there's no specific rate control
module.

Therefore, all the module handling code in rate control
is really just dead code, so remove it.

Signed-off-by: Johannes Berg

mac80211: make rate control ops const

2014-02-04T20:48:21+00:00

Change the code to allow making all the rate control ops
const, nothing ever needs to change them. Also change all
drivers to make use of this and mark the ops const.

Signed-off-by: Johannes Berg

mac80211: respect rate mask in TX

2013-10-15T13:16:29+00:00

Bitrate mask were not respected in transmissions, causing (for
example) P2P GO/client to use CCK rates for auth and assoc frames.
Fix it by considering the rate mask in __rate_control_send_low().

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

mac80211: fix honouring rate flags in low-rate transmit

2013-10-15T13:16:12+00:00

Transmissions with the IEEE80211_TX_CTL_NO_CCK_RATE flag set
(which can come from userspace) were no longer guaranteed to
be transmitted with allowed rates since commit 2103dec14792b
("mac80211: select and adjust bitrates according to channel
mode") due to a missing rate_flags check in that commit. The
commit also introduced the need to check the 5/10 MHz flags
but accidentally didn't. Fix it by adding the missing check.

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

mac80211: allow lowest basic rate for unicast management for mesh

2013-08-09T13:11:27+00:00

Allow lowest basic rate to be used for unicast management frame in
mesh. Otherwise, the lowest supported rate is used for unicast
management frame, such as 1Mbps for 2.4GHz and 6Mbps for 5GHz. Rename
the rc_send_low_broadcast to re_send_low_basicrate since now it is
also applied to unicast management frame in mesh.

Signed-off-by: Chun-Yeow Yeoh 
Signed-off-by: Johannes Berg

mac80211: select and adjust bitrates according to channel mode

2013-07-16T06:58:06+00:00

The various components accessing the bitrates table must use consider
the used channel bandwidth to select only available rates or calculate
the bitrate correctly.

There are some rates in reduced bandwidth modes which can't be
represented as multiples of 500kbps, like 2.25 MBit/s in 5 MHz mode. The
standard suggests to round up to the next multiple of 500kbps, just do
that in mac80211 as well.

Signed-off-by: Simon Wunderlich 
Signed-off-by: Mathias Kretschmer 
[make rate unsigned in ieee80211_add_tx_radiotap_header(), squash fix]
Signed-off-by: Johannes Berg