From: Johannes Berg <johannes@sipsolutions.net>
To: linux-wireless@vger.kernel.org
Cc: Pavel Roskin <proski@gnu.org>
Subject: [RFC/RFT 5/5] mac80211: re-enable re-transmission of filtered frames
Date: Tue, 15 Dec 2009 21:06:23 +0100 [thread overview]
Message-ID: <20091215200740.011405708@sipsolutions.net> (raw)
In-Reply-To: 20091215200618.253970634@sipsolutions.net
In an earlier commit,
mac80211: disable software retry for now
Pavel Roskin reported a problem that seems to be due to
software retry of already transmitted frames. It turns
out that we've never done that correctly, but due to
some recent changes it now crashes in the TX code. I've
added a comment in the patch that explains the problem
better and also points to possible solutions -- which
I can't implement right now.
I disabled software retry of failed/filtered frames
because it was broken. With the work of the previous
patches, it now becomes fairly easy to re-enable it
by adding a flag indicating that the frame shouldn't
be modified, but still running it through the transmit
handlers to populate the control information.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
include/net/mac80211.h | 4 ++++
net/mac80211/status.c | 32 +++++---------------------------
net/mac80211/tx.c | 5 +++++
3 files changed, 14 insertions(+), 27 deletions(-)
--- wireless-testing.orig/net/mac80211/status.c 2009-12-15 20:50:58.000000000 +0100
+++ wireless-testing/net/mac80211/status.c 2009-12-15 20:53:28.000000000 +0100
@@ -45,37 +45,16 @@ static void ieee80211_handle_filtered_fr
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
/*
- * XXX: This is temporary!
- *
- * The problem here is that when we get here, the driver will
- * quite likely have pretty much overwritten info->control by
- * using info->driver_data or info->rate_driver_data. Thus,
- * when passing out the frame to the driver again, we would be
- * passing completely bogus data since the driver would then
- * expect a properly filled info->control. In mac80211 itself
- * the same problem occurs, since we need info->control.vif
- * internally.
- *
- * To fix this, we should send the frame through TX processing
- * again. However, it's not that simple, since the frame will
- * have been software-encrypted (if applicable) already, and
- * encrypting it again doesn't do much good. So to properly do
- * that, we not only have to skip the actual 'raw' encryption
- * (key selection etc. still has to be done!) but also the
- * sequence number assignment since that impacts the crypto
- * encapsulation, of course.
- *
- * Hence, for now, fix the bug by just dropping the frame.
- */
- goto drop;
-
- /*
* This skb 'survived' a round-trip through the driver, and
* hopefully the driver didn't mangle it too badly. However,
* we can definitely not rely on the the control information
- * being correct. Clear it so we don't get junk there.
+ * being correct. Clear it so we don't get junk there, and
+ * indicate that it needs new processing, but must not be
+ * modified/encrypted again.
*/
memset(&info->control, 0, sizeof(info->control));
+ info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING |
+ IEEE80211_TX_INTFL_RETRANSMISSION;
sta->tx_filtered_count++;
@@ -130,7 +109,6 @@ static void ieee80211_handle_filtered_fr
return;
}
- drop:
#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
if (net_ratelimit())
printk(KERN_DEBUG "%s: dropped TX filtered frame, "
--- wireless-testing.orig/include/net/mac80211.h 2009-12-15 20:51:21.000000000 +0100
+++ wireless-testing/include/net/mac80211.h 2009-12-15 20:54:11.000000000 +0100
@@ -272,6 +272,9 @@ struct ieee80211_bss_conf {
* transmit function after the current frame, this can be used
* by drivers to kick the DMA queue only if unset or when the
* queue gets full.
+ * @IEEE80211_TX_INTFL_RETRANSMISSION: This frame is being retransmitted
+ * after TX status because the destination was asleep, it must not
+ * be modified again (no seqno assignment, crypto, etc.)
*/
enum mac80211_tx_control_flags {
IEEE80211_TX_CTL_REQ_TX_STATUS = BIT(0),
@@ -293,6 +296,7 @@ enum mac80211_tx_control_flags {
IEEE80211_TX_INTFL_DONT_ENCRYPT = BIT(16),
IEEE80211_TX_CTL_PSPOLL_RESPONSE = BIT(17),
IEEE80211_TX_CTL_MORE_FRAMES = BIT(18),
+ IEEE80211_TX_INTFL_RETRANSMISSION = BIT(19),
};
/**
--- wireless-testing.orig/net/mac80211/tx.c 2009-12-15 20:54:18.000000000 +0100
+++ wireless-testing/net/mac80211/tx.c 2009-12-15 20:55:01.000000000 +0100
@@ -1211,6 +1211,7 @@ static int __ieee80211_tx(struct ieee802
static int invoke_tx_handlers(struct ieee80211_tx_data *tx)
{
struct sk_buff *skb = tx->skb;
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
ieee80211_tx_result res = TX_DROP;
#define CALL_TXH(txh) \
@@ -1227,6 +1228,10 @@ static int invoke_tx_handlers(struct iee
CALL_TXH(ieee80211_tx_h_michael_mic_add);
if (!(tx->local->hw.flags & IEEE80211_HW_HAS_RATE_CONTROL))
CALL_TXH(ieee80211_tx_h_rate_ctrl);
+
+ if (unlikely(info->flags & IEEE80211_TX_INTFL_RETRANSMISSION))
+ goto txh_done;
+
CALL_TXH(ieee80211_tx_h_sequence);
CALL_TXH(ieee80211_tx_h_fragment);
/* handlers after fragment must be aware of tx info fragmentation! */
prev parent reply other threads:[~2009-12-15 20:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-15 20:06 [RFC/RFT 0/5] mac80211: re-enable software retry Johannes Berg
2009-12-15 20:06 ` [RFC/RFT 1/5] mac80211: move and rename misc tx handler Johannes Berg
2009-12-15 20:06 ` [RFC/RFT 2/5] mac80211: clear TX control on filtered frames Johannes Berg
2009-12-15 20:06 ` [RFC/RFT 3/5] mac80211: remove useless setting of IEEE80211_TX_INTFL_DONT_ENCRYPT Johannes Berg
2009-12-15 20:06 ` [RFC/RFT 4/5] mac80211: move control.hw_key assignment Johannes Berg
2009-12-15 20:06 ` Johannes Berg [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091215200740.011405708@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=proski@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).