2010-03-12 03:02:50

by Felix Fietkau

[permalink] [raw]
Subject: [PATCH] ath9k: fix BUG_ON triggered by PAE frames

When I initially stumbled upon sequence number problems with PAE frames
in ath9k, I submitted a patch to remove all special cases for PAE
frames and let them go through the normal transmit path.
Out of concern about crypto incompatibility issues, this change was
merged instead:

commit 6c8afef551fef87a3bf24f8a74c69a7f2f72fc82
Author: Sujith <[email protected]>
Date: Tue Feb 9 10:07:00 2010 +0530

ath9k: Fix sequence numbers for PAE frames

After a lot of testing, I'm able to reliably trigger a driver crash on
rekeying with current versions with this change in place.
It seems that the driver does not support sending out regular MPDUs with
the same TID while an A-MPDU session is active.
This leads to duplicate entries in the TID Tx buffer, which hits the
following BUG_ON in ath_tx_addto_baw():

index = ATH_BA_INDEX(tid->seq_start, bf->bf_seqno);
cindex = (tid->baw_head + index) & (ATH_TID_MAX_BUFS - 1);

BUG_ON(tid->tx_buf[cindex] != NULL);

I believe until we actually have a reproducible case of an
incompatibility with another AP using no PAE special cases, we should
simply get rid of this mess.

This patch completely fixes my crash issues in STA mode and makes it
stay connected without throughput drops or connectivity issues even
when the AP is configured to a very short group rekey interval.

Signed-off-by: Felix Fietkau <[email protected]>
Cc: [email protected]
---
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1353,25 +1353,6 @@ static enum ath9k_pkt_type get_hw_packet
return htype;
}

-static bool is_pae(struct sk_buff *skb)
-{
- struct ieee80211_hdr *hdr;
- __le16 fc;
-
- hdr = (struct ieee80211_hdr *)skb->data;
- fc = hdr->frame_control;
-
- if (ieee80211_is_data(fc)) {
- if (ieee80211_is_nullfunc(fc) ||
- /* Port Access Entity (IEEE 802.1X) */
- (skb->protocol == cpu_to_be16(ETH_P_PAE))) {
- return true;
- }
- }
-
- return false;
-}
-
static int get_hw_crypto_keytype(struct sk_buff *skb)
{
struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
@@ -1696,7 +1677,7 @@ static void ath_tx_start_dma(struct ath_
goto tx_done;
}

- if ((tx_info->flags & IEEE80211_TX_CTL_AMPDU) && !is_pae(skb)) {
+ if (tx_info->flags & IEEE80211_TX_CTL_AMPDU) {
/*
* Try aggregation if it's a unicast data frame
* and the destination is HT capable.


2010-03-15 07:04:43

by Sujith

[permalink] [raw]
Subject: [PATCH] ath9k: fix BUG_ON triggered by PAE frames

Felix Fietkau wrote:
> When I initially stumbled upon sequence number problems with PAE frames
> in ath9k, I submitted a patch to remove all special cases for PAE
> frames and let them go through the normal transmit path.
> Out of concern about crypto incompatibility issues, this change was
> merged instead:
>
> commit 6c8afef551fef87a3bf24f8a74c69a7f2f72fc82
> Author: Sujith <[email protected]>
> Date: Tue Feb 9 10:07:00 2010 +0530
>
> ath9k: Fix sequence numbers for PAE frames
>
> After a lot of testing, I'm able to reliably trigger a driver crash on
> rekeying with current versions with this change in place.
> It seems that the driver does not support sending out regular MPDUs with
> the same TID while an A-MPDU session is active.
> This leads to duplicate entries in the TID Tx buffer, which hits the
> following BUG_ON in ath_tx_addto_baw():
>
> index = ATH_BA_INDEX(tid->seq_start, bf->bf_seqno);
> cindex = (tid->baw_head + index) & (ATH_TID_MAX_BUFS - 1);
>
> BUG_ON(tid->tx_buf[cindex] != NULL);

I have seen this too, but am not sure if I was using encryption.
I have triggered this occasionally during a suspend/resume cycle.

> I believe until we actually have a reproducible case of an
> incompatibility with another AP using no PAE special cases, we should
> simply get rid of this mess.
>
> This patch completely fixes my crash issues in STA mode and makes it
> stay connected without throughput drops or connectivity issues even
> when the AP is configured to a very short group rekey interval.
>

Ok. We can remove this and see if any users report crupto problems
with random APs out there.

We did run into re-keying issues with a few APs when sending PAE
frames as part of aggregates, but unfortunately the bug reports seem
to be non-existent ...

Sujith

2010-03-12 08:47:08

by Luis R. Rodriguez

[permalink] [raw]
Subject: Re: [PATCH] ath9k: fix BUG_ON triggered by PAE frames

On Thu, Mar 11, 2010 at 7:02 PM, Felix Fietkau <[email protected]> wrote:
> When I initially stumbled upon sequence number problems with PAE frames
> in ath9k, I submitted a patch to remove all special cases for PAE
> frames and let them go through the normal transmit path.
> Out of concern about crypto incompatibility issues, this change was
> merged instead:
>
> commit 6c8afef551fef87a3bf24f8a74c69a7f2f72fc82
> Author: Sujith <[email protected]>
> Date:   Tue Feb 9 10:07:00 2010 +0530
>
>    ath9k: Fix sequence numbers for PAE frames
>
> After a lot of testing, I'm able to reliably trigger a driver crash on
> rekeying with current versions with this change in place.
> It seems that the driver does not support sending out regular MPDUs with
> the same TID while an A-MPDU session is active.
> This leads to duplicate entries in the TID Tx buffer, which hits the
> following BUG_ON in ath_tx_addto_baw():
>
>    index  = ATH_BA_INDEX(tid->seq_start, bf->bf_seqno);
>    cindex = (tid->baw_head + index) & (ATH_TID_MAX_BUFS - 1);
>
>    BUG_ON(tid->tx_buf[cindex] != NULL);
>
> I believe until we actually have a reproducible case of an
> incompatibility with another AP using no PAE special cases, we should
> simply get rid of this mess.

I believe that incompatibility does already exist, I think Sujith
knows the details. Not sure if Sujith is in today, I think he's on a
journey somewhere. Senthil, Vasanth, do you guys happen to recall?

Luis