<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/net/mac80211/tx.c, branch v4.0.2</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>mac80211: Send EAPOL frames at lowest rate</title>
<updated>2015-02-26T20:03:06+00:00</updated>
<author>
<name>Jouni Malinen</name>
<email>jouni@qca.qualcomm.com</email>
</author>
<published>2015-02-26T13:50:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9c1c98a3bb7b7593b60264b9a07e001e68b46697'/>
<id>9c1c98a3bb7b7593b60264b9a07e001e68b46697</id>
<content type='text'>
The current minstrel_ht rate control behavior is somewhat optimistic in
trying to find optimum TX rate. While this is usually fine for normal
Data frames, there are cases where a more conservative set of retry
parameters would be beneficial to make the connection more robust.

EAPOL frames are critical to the authentication and especially the
EAPOL-Key message 4/4 (the last message in the 4-way handshake) is
important to get through to the AP. If that message is lost, the only
recovery mechanism in many cases is to reassociate with the AP and start
from scratch. This can often be avoided by trying to send the frame with
more conservative rate and/or with more link layer retries.

In most cases, minstrel_ht is currently using the initial EAPOL-Key
frames for probing higher rates and this results in only five link layer
transmission attempts (one at high(ish) MCS and four at MCS0). While
this works with most APs, it looks like there are some deployed APs that
may have issues with the EAPOL frames using HT MCS immediately after
association. Similarly, there may be issues in cases where the signal
strength or radio environment is not good enough to be able to get
frames through even at couple of MCS 0 tries.

The best approach for this would likely to be to reduce the TX rate for
the last rate (3rd rate parameter in the set) to a low basic rate (say,
6 Mbps on 5 GHz and 2 or 5.5 Mbps on 2.4 GHz), but doing that cleanly
requires some more effort. For now, we can start with a simple one-liner
that forces the minimum rate to be used for EAPOL frames similarly how
the TX rate is selected for the IEEE 802.11 Management frames. This does
result in a small extra latency added to the cases where the AP would be
able to receive the higher rate, but taken into account how small number
of EAPOL frames are used, this is likely to be insignificant. A future
optimization in the minstrel_ht design can also allow this patch to be
reverted to get back to the more optimized initial TX rate.

It should also be noted that many drivers that do not use minstrel as
the rate control algorithm are already doing similar workarounds by
forcing the lowest TX rate to be used for EAPOL frames.

Cc: stable@vger.kernel.org
Reported-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Tested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The current minstrel_ht rate control behavior is somewhat optimistic in
trying to find optimum TX rate. While this is usually fine for normal
Data frames, there are cases where a more conservative set of retry
parameters would be beneficial to make the connection more robust.

EAPOL frames are critical to the authentication and especially the
EAPOL-Key message 4/4 (the last message in the 4-way handshake) is
important to get through to the AP. If that message is lost, the only
recovery mechanism in many cases is to reassociate with the AP and start
from scratch. This can often be avoided by trying to send the frame with
more conservative rate and/or with more link layer retries.

In most cases, minstrel_ht is currently using the initial EAPOL-Key
frames for probing higher rates and this results in only five link layer
transmission attempts (one at high(ish) MCS and four at MCS0). While
this works with most APs, it looks like there are some deployed APs that
may have issues with the EAPOL frames using HT MCS immediately after
association. Similarly, there may be issues in cases where the signal
strength or radio environment is not good enough to be able to get
frames through even at couple of MCS 0 tries.

The best approach for this would likely to be to reduce the TX rate for
the last rate (3rd rate parameter in the set) to a low basic rate (say,
6 Mbps on 5 GHz and 2 or 5.5 Mbps on 2.4 GHz), but doing that cleanly
requires some more effort. For now, we can start with a simple one-liner
that forces the minimum rate to be used for EAPOL frames similarly how
the TX rate is selected for the IEEE 802.11 Management frames. This does
result in a small extra latency added to the cases where the AP would be
able to receive the higher rate, but taken into account how small number
of EAPOL frames are used, this is likely to be insignificant. A future
optimization in the minstrel_ht design can also allow this patch to be
reverted to get back to the more optimized initial TX rate.

It should also be noted that many drivers that do not use minstrel as
the rate control algorithm are already doing similar workarounds by
forcing the lowest TX rate to be used for EAPOL frames.

Cc: stable@vger.kernel.org
Reported-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Tested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80111: Add BIP-GMAC-128 and BIP-GMAC-256 ciphers</title>
<updated>2015-01-27T10:10:13+00:00</updated>
<author>
<name>Jouni Malinen</name>
<email>jouni@qca.qualcomm.com</email>
</author>
<published>2015-01-24T17:52:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8ade538bf39b1ee53418528fdacd36b8e65621b9'/>
<id>8ade538bf39b1ee53418528fdacd36b8e65621b9</id>
<content type='text'>
This allows mac80211 to configure BIP-GMAC-128 and BIP-GMAC-256 to the
driver and also use software-implementation within mac80211 when the
driver does not support this with hardware accelaration.

Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This allows mac80211 to configure BIP-GMAC-128 and BIP-GMAC-256 to the
driver and also use software-implementation within mac80211 when the
driver does not support this with hardware accelaration.

Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80111: Add BIP-CMAC-256 cipher</title>
<updated>2015-01-27T10:09:13+00:00</updated>
<author>
<name>Jouni Malinen</name>
<email>jouni@qca.qualcomm.com</email>
</author>
<published>2015-01-24T17:52:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=56c52da2d554f081e8fce58ecbcf6a40c605b95b'/>
<id>56c52da2d554f081e8fce58ecbcf6a40c605b95b</id>
<content type='text'>
This allows mac80211 to configure BIP-CMAC-256 to the driver and also
use software-implementation within mac80211 when the driver does not
support this with hardware accelaration.

Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This allows mac80211 to configure BIP-CMAC-256 to the driver and also
use software-implementation within mac80211 when the driver does not
support this with hardware accelaration.

Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80111: Add CCMP-256 cipher</title>
<updated>2015-01-27T10:07:35+00:00</updated>
<author>
<name>Jouni Malinen</name>
<email>jouni@qca.qualcomm.com</email>
</author>
<published>2015-01-24T17:52:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2b2ba0db1c820d04d5143452d70012cd44d7b578'/>
<id>2b2ba0db1c820d04d5143452d70012cd44d7b578</id>
<content type='text'>
This allows mac80211 to configure CCMP-256 to the driver and also use
software-implementation within mac80211 when the driver does not support
this with hardware accelaration.

Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
[squash ccmp256 -&gt; mic_len argument change]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This allows mac80211 to configure CCMP-256 to the driver and also use
software-implementation within mac80211 when the driver does not support
this with hardware accelaration.

Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
[squash ccmp256 -&gt; mic_len argument change]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80111: Add GCMP and GCMP-256 ciphers</title>
<updated>2015-01-27T10:06:09+00:00</updated>
<author>
<name>Jouni Malinen</name>
<email>jouni@qca.qualcomm.com</email>
</author>
<published>2015-01-24T17:52:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=00b9cfa3ff38401bd70c34b250ca13e5ea347b4a'/>
<id>00b9cfa3ff38401bd70c34b250ca13e5ea347b4a</id>
<content type='text'>
This allows mac80211 to configure GCMP and GCMP-256 to the driver and
also use software-implementation within mac80211 when the driver does
not support this with hardware accelaration.

Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
[remove a spurious newline]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This allows mac80211 to configure GCMP and GCMP-256 to the driver and
also use software-implementation within mac80211 when the driver does
not support this with hardware accelaration.

Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
[remove a spurious newline]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: let flush() drop packets when possible</title>
<updated>2015-01-14T08:31:18+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2015-01-07T13:42:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3b24f4c65386dc0f2efb41027bc6e410ea2c0049'/>
<id>3b24f4c65386dc0f2efb41027bc6e410ea2c0049</id>
<content type='text'>
When roaming / suspending, it makes no sense to wait until
the transmit queues of the device are empty. In extreme
condition they can be starved (VO saturating the air), but
even in regular cases, it is pointless to delay the roaming
because the low level driver is trying to send packets to
an AP which is far away. We'd rather drop these packets and
let TCP retransmit if needed. This will allow to speed up
the roaming.

For suspend, the explanation is even more trivial.

Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When roaming / suspending, it makes no sense to wait until
the transmit queues of the device are empty. In extreme
condition they can be starved (VO saturating the air), but
even in regular cases, it is pointless to delay the roaming
because the low level driver is trying to send packets to
an AP which is far away. We'd rather drop these packets and
let TCP retransmit if needed. This will allow to speed up
the roaming.

For suspend, the explanation is even more trivial.

Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: provide per-TID RX/TX MSDU counters</title>
<updated>2015-01-08T14:28:20+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2014-11-21T13:26:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=79c892b85027d5074dfa670dd451c14ee649fb88'/>
<id>79c892b85027d5074dfa670dd451c14ee649fb88</id>
<content type='text'>
Implement the new counters cfg80211 can now advertise to userspace.
The TX code is in the sequence number handler, which is a bit odd,
but that place already knows the TID and frame type, so it was
easiest and least impact there.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Implement the new counters cfg80211 can now advertise to userspace.
The TX code is in the sequence number handler, which is a bit odd,
but that place already knows the TID and frame type, so it was
easiest and least impact there.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: add more missing checks for VHT tx rates</title>
<updated>2014-11-28T13:24:23+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2014-11-21T22:29:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=336004e29115e47253f7e7d007df9e1f9e73dcdd'/>
<id>336004e29115e47253f7e7d007df9e1f9e73dcdd</id>
<content type='text'>
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 &lt;j@w1.fi&gt;
Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;j@w1.fi&gt;
Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: allow drivers to support NL80211_SCAN_FLAG_RANDOM_ADDR</title>
<updated>2014-11-19T17:46:09+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2014-06-12T20:24:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a344d6778a98e4c19ac871f369e399e6356edcb3'/>
<id>a344d6778a98e4c19ac871f369e399e6356edcb3</id>
<content type='text'>
Allow drivers to support NL80211_SCAN_FLAG_RANDOM_ADDR with software
based scanning and generate a random MAC address for them for every
scan request with the flag.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Allow drivers to support NL80211_SCAN_FLAG_RANDOM_ADDR with software
based scanning and generate a random MAC address for them for every
scan request with the flag.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: synchronously reserve TID per station</title>
<updated>2014-11-19T17:45:36+00:00</updated>
<author>
<name>Liad Kaufman</name>
<email>liad.kaufman@intel.com</email>
</author>
<published>2014-11-19T11:47:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b6da911b3cf1d342f2f7123c9eb6463d299bca4e'/>
<id>b6da911b3cf1d342f2f7123c9eb6463d299bca4e</id>
<content type='text'>
In TDLS (e.g., TDLS off-channel) there is a requirement for
some drivers to supply an unused TID between the AP and the
device to the FW, to allow sending PTI requests and to allow
the FW to aggregate on a specific TID for better throughput.

To ensure that the allocated TID is indeed unused, this patch
introduces an API for blocking the driver from TXing on that
TID.

Signed-off-by: Liad Kaufman &lt;liad.kaufman@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In TDLS (e.g., TDLS off-channel) there is a requirement for
some drivers to supply an unused TID between the AP and the
device to the FW, to allow sending PTI requests and to allow
the FW to aggregate on a specific TID for better throughput.

To ensure that the allocated TID is indeed unused, this patch
introduces an API for blocking the driver from TXing on that
TID.

Signed-off-by: Liad Kaufman &lt;liad.kaufman@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
