Hi,
I just noticed that EAPOL frames generated by hostapd during the 4-way
handshake are sent out by mac80211 using a rate as selected by the rc
algorithm for data frames. In my case minstrel_ht selects a MCS rate for
11n clients which sometimes results in a 4-way handshake timeout under
low signal conditions.
I haven't found anything in 802.11-2007 if EAPOL frames have to be sent
at a low rate but I'd argue that it makes sense to send them at a basic
rate just like it's done for management frames.
We've got a nice little helper in mac80211 (rate_control_send_low) that
allows the rc algorithm to check if a frame should be sent at a low rate.
I thought I'd hook in there and just check skb->protocol to force EAPOL
frames to the lowest rate. However, this didn't work out because in AP
mode the EAPOL frames are injected through a monitor interface and as
such skb->protocol is never initialized (ieee80211_monitor_start_xmit).
The injected frames however already have an 802.11 header and therefore
figuring out the ethertype of the injected frame is not as straightforward as
I liked it to be :(
Can I always be sure that an injected data frame (!=nullfunc) has a rfc1042
header following after the 802.11 header?
Another option would be to let hostapd specify a fixed tx rate in the radiotap
header (and extend mac80211 to understand it). However, since some drivers
also make use of skb->protocol (to forbid aggregation for example) it sounds
more sane to initialize it also for injected frames.
Any other ideas?
Thanks,
Helmut
On Fri, Jul 29, 2011 at 11:14:20AM +0200, Helmut Schaa wrote:
> I just noticed that EAPOL frames generated by hostapd during the 4-way
> handshake are sent out by mac80211 using a rate as selected by the rc
> algorithm for data frames. In my case minstrel_ht selects a MCS rate for
> 11n clients which sometimes results in a 4-way handshake timeout under
> low signal conditions.
That sounds like an issue that should be fixed in the rate control
algorithm if it is indeed using unsuitable rate immediately after
association. Dropping data frames completely is not really a good thing
regardless of whether they are EAPOL packets or not..
> I haven't found anything in 802.11-2007 if EAPOL frames have to be sent
> at a low rate but I'd argue that it makes sense to send them at a basic
> rate just like it's done for management frames.
There is no such requirement in the standard and I don't see why basic
rates would necessarily be better for this use. Basic rate set is just a
common set of rates that can be used for broadcast/multicast since all
stations in the BSS are known to support them. The EAPOL frames here are
sent as unicast frames.
> We've got a nice little helper in mac80211 (rate_control_send_low) that
> allows the rc algorithm to check if a frame should be sent at a low rate.
> I thought I'd hook in there and just check skb->protocol to force EAPOL
> frames to the lowest rate. However, this didn't work out because in AP
> mode the EAPOL frames are injected through a monitor interface and as
> such skb->protocol is never initialized (ieee80211_monitor_start_xmit).
Some EAPOL frames can be quite large (e.g., EAP-TLS). Forcing those to
go out at 1 Mbps on a congested 2.4 GHz band channel sounds like a bad
idea in general if the stations would be able to use HT rates at the
time..
--
Jouni Malinen PGP id EFC895FA
Mohammed Shafi schrieb:
> On Fri, Jul 29, 2011 at 3:50 PM, Mohammed Shafi
> <[email protected]> wrote:
>> On Fri, Jul 29, 2011 at 2:44 PM, Helmut Schaa
>> <[email protected]> wrote:
>>> Hi,
>>>
>> Hi Helmut,
>>
>>> I just noticed that EAPOL frames generated by hostapd during the 4-way
>>> handshake are sent out by mac80211 using a rate as selected by the rc
>>> algorithm for data frames. In my case minstrel_ht selects a MCS rate for
>>> 11n clients which sometimes results in a 4-way handshake timeout under
>>> low signal conditions.
>>
>> I am occasionally seeing this issue in ath9k Station under heavy
>> traffic conditions
>> and low signal(only when I the distance between STA and AP is very
>> much significant),
>> some times I could no recreate the issue. I use ath9k-rate control and
>> I still found that the
>> EAPOL frames are being sent at lower rate.
>> with the sniffer capture there are lot of retries for 2nd message.
>> the timeout comes after 2nd message
>
> I might have missed out. looking back at one of the sniffer capture
> it seems the AP(very reliable one) is sending EAPOL to my STA at 1Mbps
> while the STA does not seems to be sending at legacy rate.
Well, that's what I always can see, too: the supplicant get's the 3/4
packet and says, it would be ok, after it send the 4/4 packet. But I
can't say, if this packet really ever gets send out or if hostapd just
doesn't see it even though it was send. Fact is: hostapd reports the 4/4
packet as missing and breaks the connection after the defined number of
retries.
Besides that, I see this problem always under middle or high load,
seldom (or never?) on low load or during idle state.
Andreas
On 2011-07-29 7:55 PM, Helmut Schaa wrote:
> On Fri, Jul 29, 2011 at 7:37 PM, Jouni Malinen<[email protected]> wrote:
>> On Fri, Jul 29, 2011 at 11:14:20AM +0200, Helmut Schaa wrote:
>>> I just noticed that EAPOL frames generated by hostapd during the 4-way
>>> handshake are sent out by mac80211 using a rate as selected by the rc
>>> algorithm for data frames. In my case minstrel_ht selects a MCS rate for
>>> 11n clients which sometimes results in a 4-way handshake timeout under
>>> low signal conditions.
>>
>> That sounds like an issue that should be fixed in the rate control
>> algorithm if it is indeed using unsuitable rate immediately after
>> association. Dropping data frames completely is not really a good thing
>> regardless of whether they are EAPOL packets or not..
>
> True. Nevertheless other drivers like madwifi or the ralink legacy drivers also
> force EAPOL frames to a low rate. That's why I had the idea in the first place.
I think this mainly occurs on devices/drivers that use minstrel_ht, but
lack proper multi-rate retry. minstrel_ht may pick a high rate for
probing and on devices with a simple fallback table (e.g. rt2x00), it
may give up on the frame before having tried a low enough rate.
On ath9k this shouldn't be an issue with minstrel_ht, because it always
keeps the max_prob_rate in a retry slot.
- Felix
On Fri, Jul 29, 2011 at 3:50 PM, Mohammed Shafi
<[email protected]> wrote:
> On Fri, Jul 29, 2011 at 2:44 PM, Helmut Schaa
> <[email protected]> wrote:
>> Hi,
>>
> Hi Helmut,
>
>> I just noticed that EAPOL frames generated by hostapd during the 4-way
>> handshake are sent out by mac80211 using a rate as selected by the rc
>> algorithm for data frames. In my case minstrel_ht selects a MCS rate for
>> 11n clients which sometimes results in a 4-way handshake timeout under
>> low signal conditions.
>
> I am occasionally seeing this issue in ath9k Station under ?heavy
> traffic conditions
> and low signal(only when I the distance between STA and AP is very
> much significant),
> some times I could no recreate the issue. I use ath9k-rate control and
> I still found that the
> EAPOL frames are being sent at lower rate.
> with the sniffer capture there are lot of retries for 2nd message.
> the timeout comes after 2nd message
I might have missed out. looking back at one of the sniffer capture
it seems the AP(very reliable one) is sending EAPOL to my STA at 1Mbps
while the STA does not seems to be sending at legacy rate.
>
>>
>> I haven't found anything in 802.11-2007 if EAPOL frames have to be sent
>> at a low rate but I'd argue that it makes sense to send them at a basic
>> rate just like it's done for management frames.
let me try I can send it in lower rate and fixes the issue.
>>
>> We've got a nice little helper in mac80211 (rate_control_send_low) that
>> allows the rc algorithm to check if a frame should be sent at a low rate.
>> I thought I'd hook in there and just check skb->protocol to force EAPOL
>> frames to the lowest rate. However, this didn't work out because in AP
>> mode the EAPOL frames are injected through a monitor interface and as
>> such skb->protocol is never initialized (ieee80211_monitor_start_xmit).
>>
>> The injected frames however already have an 802.11 header and therefore
>> figuring out the ethertype of the injected frame is not as straightforward as
>> I liked it to be :(
>>
>> Can I always be sure that an injected data frame (!=nullfunc) has a rfc1042
>> header following after the 802.11 header?
>>
>> Another option would be to let hostapd specify a fixed tx rate in the radiotap
>> header (and extend mac80211 to understand it). However, since some drivers
>> also make use of skb->protocol (to forbid aggregation for example) it sounds
>> more sane to initialize it also for injected frames.
>
> in ath9k Raj pointed out that we are not doing aggregation if the
> frame is of EAPOL, I can
> check if I am missing something.
>
>
>>
>> Any other ideas?
>>
>> Thanks,
>> Helmut
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to [email protected]
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> shafi
>
--
shafi
On Fri, Jul 29, 2011 at 7:37 PM, Jouni Malinen <[email protected]> wrote:
> On Fri, Jul 29, 2011 at 11:14:20AM +0200, Helmut Schaa wrote:
>> I just noticed that EAPOL frames generated by hostapd during the 4-way
>> handshake are sent out by mac80211 using a rate as selected by the rc
>> algorithm for data frames. In my case minstrel_ht selects a MCS rate for
>> 11n clients which sometimes results in a 4-way handshake timeout under
>> low signal conditions.
>
> That sounds like an issue that should be fixed in the rate control
> algorithm if it is indeed using unsuitable rate immediately after
> association. Dropping data frames completely is not really a good thing
> regardless of whether they are EAPOL packets or not..
True. Nevertheless other drivers like madwifi or the ralink legacy drivers also
force EAPOL frames to a low rate. That's why I had the idea in the first place.
> Some EAPOL frames can be quite large (e.g., EAP-TLS). Forcing those to
> go out at 1 Mbps on a congested 2.4 GHz band channel sounds like a bad
> idea in general if the stations would be able to use HT rates at the
> time..
Good point.
Helmut
On Fri, Jul 29, 2011 at 2:44 PM, Helmut Schaa
<[email protected]> wrote:
> Hi,
>
Hi Helmut,
> I just noticed that EAPOL frames generated by hostapd during the 4-way
> handshake are sent out by mac80211 using a rate as selected by the rc
> algorithm for data frames. In my case minstrel_ht selects a MCS rate for
> 11n clients which sometimes results in a 4-way handshake timeout under
> low signal conditions.
I am occasionally seeing this issue in ath9k Station under heavy
traffic conditions
and low signal(only when I the distance between STA and AP is very
much significant),
some times I could no recreate the issue. I use ath9k-rate control and
I still found that the
EAPOL frames are being sent at lower rate.
with the sniffer capture there are lot of retries for 2nd message.
the timeout comes after 2nd message
>
> I haven't found anything in 802.11-2007 if EAPOL frames have to be sent
> at a low rate but I'd argue that it makes sense to send them at a basic
> rate just like it's done for management frames.
>
> We've got a nice little helper in mac80211 (rate_control_send_low) that
> allows the rc algorithm to check if a frame should be sent at a low rate.
> I thought I'd hook in there and just check skb->protocol to force EAPOL
> frames to the lowest rate. However, this didn't work out because in AP
> mode the EAPOL frames are injected through a monitor interface and as
> such skb->protocol is never initialized (ieee80211_monitor_start_xmit).
>
> The injected frames however already have an 802.11 header and therefore
> figuring out the ethertype of the injected frame is not as straightforward as
> I liked it to be :(
>
> Can I always be sure that an injected data frame (!=nullfunc) has a rfc1042
> header following after the 802.11 header?
>
> Another option would be to let hostapd specify a fixed tx rate in the radiotap
> header (and extend mac80211 to understand it). However, since some drivers
> also make use of skb->protocol (to forbid aggregation for example) it sounds
> more sane to initialize it also for injected frames.
in ath9k Raj pointed out that we are not doing aggregation if the
frame is of EAPOL, I can
check if I am missing something.
>
> Any other ideas?
>
> Thanks,
> Helmut
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
--
shafi
On Fri, Jul 29, 2011 at 11:05 AM, Felix Fietkau <[email protected]> wrote:
> On 2011-07-29 7:55 PM, Helmut Schaa wrote:
>>
>> On Fri, Jul 29, 2011 at 7:37 PM, Jouni Malinen<[email protected]> wrote:
>>>
>>> On Fri, Jul 29, 2011 at 11:14:20AM +0200, Helmut Schaa wrote:
>>>>
>>>> I just noticed that EAPOL frames generated by hostapd during the 4-way
>>>> handshake are sent out by mac80211 using a rate as selected by the rc
>>>> algorithm for data frames. In my case minstrel_ht selects a MCS rate
>>>> for
>>>> 11n clients which sometimes results in a 4-way handshake timeout under
>>>> low signal conditions.
>>>
>>>
>>> That sounds like an issue that should be fixed in the rate control
>>> algorithm if it is indeed using unsuitable rate immediately after
>>> association. Dropping data frames completely is not really a good thing
>>> regardless of whether they are EAPOL packets or not..
>>
>>
>> True. Nevertheless other drivers like madwifi or the ralink legacy drivers
>> also
>> force EAPOL frames to a low rate. That's why I had the idea in the first
>> place.
>
> I think this mainly occurs on devices/drivers that use minstrel_ht, but lack
> proper multi-rate retry. minstrel_ht may pick a high rate for probing and on
> devices with a simple fallback table (e.g. rt2x00), it may give up on the
> frame before having tried a low enough rate.
>
> On ath9k this shouldn't be an issue with minstrel_ht, because it always
> keeps the max_prob_rate in a retry slot.
[reviving an old thread]
The problem is that with other algorithms (like the ath9k built-in
rate control algorithm) this may not be the case. Even in the case
where a "probable" rate is left in the the bottom retry slot, in a
congested network that may just mean you end up with one "reasonable
probability" shot -- not exactly foolproof. Based on experiences
we've been gaining on various classroom deployments and home scenarios
in ChromeOS, we've found that EAP/EAPOL frames as well as DHCP are
particularly vulnerable to creating large disruptions in connectivity
-- either significantly lengthening or completely stymying connection
attempts. DNS is somewhat vulnerable as well, but the penalty for
failure there, though user-visible, is more mitigable in the
application. Due to the small number of outgoing retries in all of
these algorithms and the penalty for failure, it seems like we should
do a better job of giving such attempts a chance to succeed.
I'd like to gauge whether adding flag to supplicant / cfg80211 to
explicitly curtail "optimism" on the part of the rate control
algorithm during this period of time would be acceptable upstream.
This flag would cause rate control to shift more of the retries into
more conservative bit-rates, and would be cleared by the connection
manager through wpa_supplicant in a similar manner to the "authorized"
flag used to curtail outbound traffic until authentication completes.
Depending on the underlying driver implementation the response could
be (a) do nothing (my rate control algorithm is awesome an all tx'ed
packets _always_ go through), (b) set a fixed retry rate sequence, (c)
change parameters in the rc algorithm to dive deeper (and stay deeper)
into the rate table on transmit failure.
--
Paul
>
> - Felix
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html