summaryrefslogtreecommitdiffstats
path: root/net/mac80211
diff options
context:
space:
mode:
authorJohannes Berg <johannes@sipsolutions.net>2009-07-27 20:28:40 +0200
committerJohn W. Linville <linville@tuxdriver.com>2009-08-04 16:43:18 -0400
commit4da163ab0a224590f3cae67c1d54ae8c428f6223 (patch)
tree901e5929df0b72ffccb84ba5ec439ac709f78705 /net/mac80211
parente4c4e448cf557921ffbbbd6d6ddac81fdceacb4f (diff)
downloadop-kernel-dev-4da163ab0a224590f3cae67c1d54ae8c428f6223.zip
op-kernel-dev-4da163ab0a224590f3cae67c1d54ae8c428f6223.tar.gz
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. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Diffstat (limited to 'net/mac80211')
-rw-r--r--net/mac80211/main.c26
1 files changed, 26 insertions, 0 deletions
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index c1a7991..9dd8d25 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -310,6 +310,31 @@ static void ieee80211_handle_filtered_frame(struct ieee80211_local *local,
{
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;
+
sta->tx_filtered_count++;
/*
@@ -363,6 +388,7 @@ static void ieee80211_handle_filtered_frame(struct ieee80211_local *local,
return;
}
+ drop:
#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
if (net_ratelimit())
printk(KERN_DEBUG "%s: dropped TX filtered frame, "
OpenPOWER on IntegriCloud