Some drivers (ath9k for example) are using skb->protocol to treat EAPOL
frames somehow special (disallow aggregation for example).
When running in AP mode hostapd injects the EAPOL frames through a
monitor interface and thus skb->protocol isn't set at all. Hence, if the
injected frame is a data frame and carries a rfc1042 headaer update the
skb->protocol field accordingly.
Signed-off-by: Helmut Schaa <[email protected]>
---
net/mac80211/tx.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index b83de4e..939c3f0 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1631,7 +1631,9 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
struct ieee80211_radiotap_header *prthdr =
(struct ieee80211_radiotap_header *)skb->data;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ struct ieee80211_hdr *hdr;
u16 len_rthdr;
+ u8 *payload;
/*
* Frame injection is not allowed if beaconing is not allowed
@@ -1682,6 +1684,24 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
skb_set_network_header(skb, len_rthdr);
skb_set_transport_header(skb, len_rthdr);
+ /*
+ * Initialize skb->protocol if the injected frame is a data frame
+ * carrying a rfc1042 header
+ */
+ if (skb->len > len_rthdr + 2) {
+ hdr = (struct ieee80211_hdr *)(skb->data + len_rthdr);
+ if (ieee80211_is_data(hdr->frame_control) &&
+ skb->len >= len_rthdr +
+ ieee80211_hdrlen(hdr->frame_control) +
+ sizeof(rfc1042_header) + 2) {
+ payload = (u8 *)hdr +
+ ieee80211_hdrlen(hdr->frame_control);
+ if (compare_ether_addr(payload, rfc1042_header) == 0)
+ skb->protocol = ntohs((payload[6] << 8) |
+ payload[7]);
+ }
+ }
+
memset(info, 0, sizeof(*info));
info->flags |= IEEE80211_TX_CTL_REQ_TX_STATUS;
--
1.7.3.4
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
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
On Fri, Jul 29, 2011 at 7:56 PM, Helmut Schaa
<[email protected]> wrote:
> On Fri, Jul 29, 2011 at 7:51 PM, Felix Fietkau <[email protected]> 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?
On 2011-07-29 8:00 PM, Helmut Schaa wrote:
> On Fri, Jul 29, 2011 at 7:56 PM, Helmut Schaa
> <[email protected]> wrote:
>> On Fri, Jul 29, 2011 at 7:51 PM, Felix Fietkau<[email protected]> 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
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
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
On Fri, Jul 29, 2011 at 8:05 PM, Felix Fietkau <[email protected]> wrote:
> On 2011-07-29 8:00 PM, Helmut Schaa wrote:
>>
>> On Fri, Jul 29, 2011 at 7:56 PM, Helmut Schaa
>> <[email protected]> ?wrote:
>>>
>>> ?On Fri, Jul 29, 2011 at 7:51 PM, Felix Fietkau<[email protected]> ?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.
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 PGP id EFC895FA
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 <[email protected]>
---
net/mac80211/rate.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
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) ?
--
1.7.3.4
On Fri, Jul 29, 2011 at 7:51 PM, Felix Fietkau <[email protected]> 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
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
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