| Message ID | 1311960137-25420-2-git-send-email-helmut.schaa@googlemail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On 2011-07-29 7:22 PM, Helmut Schaa wrote: > Since EAPOL frames are normal data frames they are treated by the rate > control algorithm as such. Thus it can happen that the rate control > algorithm chooses an inappropriate rate (minstrel_ht uses MCS rates for > example) for the 4-way handshake and under low signal conditions the > handshake may time out. > > To fix this issue always treat EAPOL frames the same as management > frames and send them with the lowest available rate. Have you tried preventing minstrel_ht from using EAPOL frames for probing different rates instead of forcing it to use the lowest rate? - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 29, 2011 at 7:51 PM, Felix Fietkau <nbd@openwrt.org> wrote: > On 2011-07-29 7:22 PM, Helmut Schaa wrote: >> >> Since EAPOL frames are normal data frames they are treated by the rate >> control algorithm as such. Thus it can happen that the rate control >> algorithm chooses an inappropriate rate (minstrel_ht uses MCS rates for >> example) for the 4-way handshake and under low signal conditions the >> handshake may time out. >> >> To fix this issue always treat EAPOL frames the same as management >> frames and send them with the lowest available rate. > > Have you tried preventing minstrel_ht from using EAPOL frames for probing > different rates instead of forcing it to use the lowest rate? Nope. I'll give it a try soon. Thanks, Helmut -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 29, 2011 at 7:56 PM, Helmut Schaa <helmut.schaa@googlemail.com> wrote: > On Fri, Jul 29, 2011 at 7:51 PM, Felix Fietkau <nbd@openwrt.org> wrote: >> On 2011-07-29 7:22 PM, Helmut Schaa wrote: >>> >>> Since EAPOL frames are normal data frames they are treated by the rate >>> control algorithm as such. Thus it can happen that the rate control >>> algorithm chooses an inappropriate rate (minstrel_ht uses MCS rates for >>> example) for the 4-way handshake and under low signal conditions the >>> handshake may time out. >>> >>> To fix this issue always treat EAPOL frames the same as management >>> frames and send them with the lowest available rate. >> >> Have you tried preventing minstrel_ht from using EAPOL frames for probing >> different rates instead of forcing it to use the lowest rate? > > Nope. I'll give it a try soon. Felix, what rate is used by minstrel_ht if there are no statistics yet? MCS0? -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2011-07-29 8:00 PM, Helmut Schaa wrote: > On Fri, Jul 29, 2011 at 7:56 PM, Helmut Schaa > <helmut.schaa@googlemail.com> wrote: >> On Fri, Jul 29, 2011 at 7:51 PM, Felix Fietkau<nbd@openwrt.org> wrote: >>> On 2011-07-29 7:22 PM, Helmut Schaa wrote: >>>> >>>> Since EAPOL frames are normal data frames they are treated by the rate >>>> control algorithm as such. Thus it can happen that the rate control >>>> algorithm chooses an inappropriate rate (minstrel_ht uses MCS rates for >>>> example) for the 4-way handshake and under low signal conditions the >>>> handshake may time out. >>>> >>>> To fix this issue always treat EAPOL frames the same as management >>>> frames and send them with the lowest available rate. >>> >>> Have you tried preventing minstrel_ht from using EAPOL frames for probing >>> different rates instead of forcing it to use the lowest rate? >> >> Nope. I'll give it a try soon. > > Felix, what rate is used by minstrel_ht if there are no statistics yet? MCS0? Yes, rates default to lowest until better ones are available. - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 29, 2011 at 8:05 PM, Felix Fietkau <nbd@openwrt.org> wrote: > On 2011-07-29 8:00 PM, Helmut Schaa wrote: >> >> On Fri, Jul 29, 2011 at 7:56 PM, Helmut Schaa >> <helmut.schaa@googlemail.com> wrote: >>> >>> On Fri, Jul 29, 2011 at 7:51 PM, Felix Fietkau<nbd@openwrt.org> wrote: >>>> >>>> On 2011-07-29 7:22 PM, Helmut Schaa wrote: >>>>> >>>>> Since EAPOL frames are normal data frames they are treated by the rate >>>>> control algorithm as such. Thus it can happen that the rate control >>>>> algorithm chooses an inappropriate rate (minstrel_ht uses MCS rates >>>>> for >>>>> example) for the 4-way handshake and under low signal conditions the >>>>> handshake may time out. >>>>> >>>>> To fix this issue always treat EAPOL frames the same as management >>>>> frames and send them with the lowest available rate. >>>> >>>> Have you tried preventing minstrel_ht from using EAPOL frames for >>>> probing >>>> different rates instead of forcing it to use the lowest rate? >>> >>> Nope. I'll give it a try soon. >> >> Felix, what rate is used by minstrel_ht if there are no statistics yet? >> MCS0? > > Yes, rates default to lowest until better ones are available. Ok, I'll try if forbidding rate probing for EAPOL frames in minstrel_ht solves this problem. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 29, 2011 at 07:22:17PM +0200, Helmut Schaa wrote: > Since EAPOL frames are normal data frames they are treated by the rate > control algorithm as such. Thus it can happen that the rate control > algorithm chooses an inappropriate rate (minstrel_ht uses MCS rates for > example) for the 4-way handshake and under low signal conditions the > handshake may time out. > > To fix this issue always treat EAPOL frames the same as management > frames and send them with the lowest available rate. I don't think that this should be applied for the reasons given (and alternative mechanisms proposed) in the discussion.
Jouni Malinen schrieb: > On Fri, Jul 29, 2011 at 07:22:17PM +0200, Helmut Schaa wrote: >> Since EAPOL frames are normal data frames they are treated by the >> rate control algorithm as such. Thus it can happen that the rate >> control algorithm chooses an inappropriate rate (minstrel_ht uses >> MCS rates for example) for the 4-way handshake and under low signal >> conditions the handshake may time out. >> >> To fix this issue always treat EAPOL frames the same as management >> frames and send them with the lowest available rate. > > I don't think that this should be applied for the reasons given (and > alternative mechanisms proposed) in the discussion. I tested it with AP (rt2860) (with STA rt3572sta) under load and couldn't see any improvement. The first PTK-rekeying didn't work as usual. Or should it be applied to STA? Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 30 July 2011 22:03:34 Andreas Hartmann wrote: > Jouni Malinen schrieb: > > On Fri, Jul 29, 2011 at 07:22:17PM +0200, Helmut Schaa wrote: > >> Since EAPOL frames are normal data frames they are treated by the > >> rate control algorithm as such. Thus it can happen that the rate > >> control algorithm chooses an inappropriate rate (minstrel_ht uses > >> MCS rates for example) for the 4-way handshake and under low signal > >> conditions the handshake may time out. > >> > >> To fix this issue always treat EAPOL frames the same as management > >> frames and send them with the lowest available rate. > > > > I don't think that this should be applied for the reasons given (and > > alternative mechanisms proposed) in the discussion. > > I tested it with AP (rt2860) (with STA rt3572sta) under load and > couldn't see any improvement. The first PTK-rekeying didn't work as > usual. Or should it be applied to STA? might be a shot into the dark. But who's assigning a proper frame sequence to each eapol? Hostapd certainly can't because it doesn't know what's the current sequence at the moment... and mac80211 won't assign one because the frame is injected by a monitor interface. So when the receiver gets the EAPOL it might drops it because the empty sequence might be not in the BA window anymore. Does this sound reasonable, or did I miss something? Regards, Chr -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Christian Lamparter schrieb: > On Saturday 30 July 2011 22:03:34 Andreas Hartmann wrote: >> Jouni Malinen schrieb: >>> On Fri, Jul 29, 2011 at 07:22:17PM +0200, Helmut Schaa wrote: >>>> Since EAPOL frames are normal data frames they are treated by the >>>> rate control algorithm as such. Thus it can happen that the rate >>>> control algorithm chooses an inappropriate rate (minstrel_ht uses >>>> MCS rates for example) for the 4-way handshake and under low signal >>>> conditions the handshake may time out. >>>> >>>> To fix this issue always treat EAPOL frames the same as management >>>> frames and send them with the lowest available rate. >>> >>> I don't think that this should be applied for the reasons given (and >>> alternative mechanisms proposed) in the discussion. >> >> I tested it with AP (rt2860) (with STA rt3572sta) under load and >> couldn't see any improvement. The first PTK-rekeying didn't work as >> usual. Or should it be applied to STA? > > might be a shot into the dark. But who's assigning a proper frame sequence > to each eapol? Hostapd certainly can't because it doesn't know what's the > current sequence at the moment... and mac80211 won't assign one because > the frame is injected by a monitor interface. So when the receiver gets the > EAPOL it might drops it because the empty sequence might be not in the > BA window anymore. Does this sound reasonable, or did I miss something? Meanwhile I tested with the patch on both sides, AP (rt2800pci / rt2860) and STA (ath9k / ar9582) and compat-wireless-2011-07-28. The result is unchanged the same: the first ptk rekeying (4 way handshake) just didn't work. Another thing: I don't think, that the wireless modules are the reason of the problem. If I'm using the following test setup, I get no problem at all: AP: (rt2800pci / rt2860 - without patch) STA: (rt3572 / rt3572sta - used without wpa_supplicant, but just rt3572sta stack - rt3572sta ships with an own WPA2-PSK-stack) -> Why is it working without any problems, if wpa_supplicant isn't used at all? Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Samstag, 30. Juli 2011, 21:28:10 schrieb Jouni Malinen: > On Fri, Jul 29, 2011 at 07:22:17PM +0200, Helmut Schaa wrote: > > Since EAPOL frames are normal data frames they are treated by the rate > > control algorithm as such. Thus it can happen that the rate control > > algorithm chooses an inappropriate rate (minstrel_ht uses MCS rates for > > example) for the 4-way handshake and under low signal conditions the > > handshake may time out. > > > > To fix this issue always treat EAPOL frames the same as management > > frames and send them with the lowest available rate. > > I don't think that this should be applied for the reasons given (and > alternative mechanisms proposed) in the discussion. Agreed, I'll do some more tests with Felix suggestion to prevent minstrel_ht from rate sampling on EAPOL frames. John, please drop this one. Thanks, Helmut -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Samstag, 30. Juli 2011, 22:03:34 schrieb Andreas Hartmann: > Jouni Malinen schrieb: > > On Fri, Jul 29, 2011 at 07:22:17PM +0200, Helmut Schaa wrote: > >> Since EAPOL frames are normal data frames they are treated by the > >> rate control algorithm as such. Thus it can happen that the rate > >> control algorithm chooses an inappropriate rate (minstrel_ht uses > >> MCS rates for example) for the 4-way handshake and under low signal > >> conditions the handshake may time out. > >> > >> To fix this issue always treat EAPOL frames the same as management > >> frames and send them with the lowest available rate. > > > > I don't think that this should be applied for the reasons given (and > > alternative mechanisms proposed) in the discussion. > > I tested it with AP (rt2860) (with STA rt3572sta) under load and > couldn't see any improvement. Because the patch never intended to tackle the problem you've reported :) However, I've got some reports of clients timing out during the 4-way handshake if they are "far" away from the AP while auth and assoc work just fine. Helmut -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c index 3d5a2cb..c307b7b 100644 --- a/net/mac80211/rate.c +++ b/net/mac80211/rate.c @@ -199,6 +199,13 @@ static void rate_control_release(struct kref *kref) kfree(ctrl_ref); } +static bool rc_is_port_control(struct ieee80211_sta *pubsta, + struct ieee80211_tx_rate_control *txrc) +{ + struct sta_info *sta = container_of(pubsta, struct sta_info, sta); + return sta->sdata->control_port_protocol == txrc->skb->protocol; +} + static bool rc_no_data_or_no_ack(struct ieee80211_tx_rate_control *txrc) { struct sk_buff *skb = txrc->skb; @@ -241,7 +248,8 @@ bool rate_control_send_low(struct ieee80211_sta *sta, struct ieee80211_supported_band *sband = txrc->sband; int mcast_rate; - if (!sta || !priv_sta || rc_no_data_or_no_ack(txrc)) { + if (!sta || !priv_sta || rc_no_data_or_no_ack(txrc) || + rc_is_port_control(sta, txrc)) { info->control.rates[0].idx = rate_lowest_index(txrc->sband, sta); info->control.rates[0].count = (info->flags & IEEE80211_TX_CTL_NO_ACK) ?
Since EAPOL frames are normal data frames they are treated by the rate control algorithm as such. Thus it can happen that the rate control algorithm chooses an inappropriate rate (minstrel_ht uses MCS rates for example) for the 4-way handshake and under low signal conditions the handshake may time out. To fix this issue always treat EAPOL frames the same as management frames and send them with the lowest available rate. Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> --- net/mac80211/rate.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-)