Always send management frames at MCS-0??

Always send management frames at MCS-0??

[Ben Greear]

I had a user request that we support always sending management frames
(such as EAPOL) at the lowest rate.  Evidently, other equipment does this,
where as normal-ish supplicant/linux tends to send them at much higher
rates.

Any suggestions on how to go about doing this properly?

Any opinions on whether it's a good idea or not?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Always send management frames at MCS-0??

[Krishna Chaitanya]

On Tue, Sep 10, 2013 at 12:40 AM, Ben Greear <greearb@candelatech.com> wrote:
> I had a user request that we support always sending management frames
> (such as EAPOL) at the lowest rate.  Evidently, other equipment does this,
> where as normal-ish supplicant/linux tends to send them at much higher
> rates.
>
> Any suggestions on how to go about doing this properly?
>
> Any opinions on whether it's a good idea or not?

EAPOL frames are data frams from WLAN perspective
and are unicast, thats why we send at highest possible
MCS supported. There is no advantage in forcing them to
go at lower rates.

Re: Always send management frames at MCS-0??

[Ben Greear]

On 09/09/2013 12:15 PM, Krishna Chaitanya wrote:
> On Tue, Sep 10, 2013 at 12:40 AM, Ben Greear <greearb@candelatech.com> wrote:
>> I had a user request that we support always sending management frames
>> (such as EAPOL) at the lowest rate.  Evidently, other equipment does this,
>> where as normal-ish supplicant/linux tends to send them at much higher
>> rates.
>>
>> Any suggestions on how to go about doing this properly?
>>
>> Any opinions on whether it's a good idea or not?
>
> EAPOL frames are data frams from WLAN perspective
> and are unicast, thats why we send at highest possible
> MCS supported. There is no advantage in forcing them to
> go at lower rates.
>

Would forcing them to a lower rate at least theoretically improve
the chance that the packets are properly delivered?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Always send management frames at MCS-0??

[Sujith Manoharan]

Ben Greear wrote:
> I had a user request that we support always sending management frames
> (such as EAPOL) at the lowest rate.  Evidently, other equipment does this,
> where as normal-ish supplicant/linux tends to send them at much higher
> rates.
> 
> Any suggestions on how to go about doing this properly?

If this is with ath9k_rate_control, then it is a known bug:
https://bugzilla.redhat.com/show_bug.cgi?id=927191

Sujith

Re: Always send management frames at MCS-0??

[Krishna Chaitanya]

On Tue, Sep 10, 2013 at 4:40 AM, Ben Greear <greearb@candelatech.com> wrote:

> Would forcing them to a lower rate at least theoretically improve
> the chance that the packets are properly delivered?
Yes. But we already have a RC algorithm taking care of that.
Right?

Re: Always send management frames at MCS-0??

[Dan Williams]

On Tue, 2013-09-10 at 14:47 +0530, Krishna Chaitanya wrote:
> On Tue, Sep 10, 2013 at 4:40 AM, Ben Greear <greearb@candelatech.com> wrote:
> 
> > Would forcing them to a lower rate at least theoretically improve
> > the chance that the packets are properly delivered?
> Yes. But we already have a RC algorithm taking care of that.
> Right?

Except if there's periodic interference, like a microwave.  In this
case, where the microwave cycles on and off, the longer it takes to
transmit the frame (ie, a lower rate) the *more* likely it is to get
partially squelched by the microwave turning on in its next cycle.  Here
a faster rate can be more robust since it can transmit the entire frame
in between microwave cycles.

Dan

Re: Always send management frames at MCS-0??

[Ben Greear]

On 09/10/2013 01:10 AM, Sujith Manoharan wrote:
> Ben Greear wrote:
>> I had a user request that we support always sending management frames
>> (such as EAPOL) at the lowest rate.  Evidently, other equipment does this,
>> where as normal-ish supplicant/linux tends to send them at much higher
>> rates.
>>
>> Any suggestions on how to go about doing this properly?
>
> If this is with ath9k_rate_control, then it is a known bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=927191

I'm not using ath9k rate control in this case, and at least most messages
get through fine.  We didn't actually see any obvious improvement when forcing
everything to 6Mbps, but since my user was asking, I wanted to run the
idea past the list.

Rate control is not perfect, and on initial bringup it doesn't have
many packets to work with so I thought it might still be useful to allow
users to specify a particular rate for EAPOL packets.  Maybe using
a socket ioctl so user-space (ie, supplicant/hostapd) can control it,
for example.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Always send management frames at MCS-0??

[Felix Fietkau]

On 2013-09-10 5:48 PM, Ben Greear wrote:
> On 09/10/2013 01:10 AM, Sujith Manoharan wrote:
>> Ben Greear wrote:
>>> I had a user request that we support always sending management frames
>>> (such as EAPOL) at the lowest rate.  Evidently, other equipment does this,
>>> where as normal-ish supplicant/linux tends to send them at much higher
>>> rates.
>>>
>>> Any suggestions on how to go about doing this properly?
>>
>> If this is with ath9k_rate_control, then it is a known bug:
>> https://bugzilla.redhat.com/show_bug.cgi?id=927191
> 
> I'm not using ath9k rate control in this case, and at least most messages
> get through fine.  We didn't actually see any obvious improvement when forcing
> everything to 6Mbps, but since my user was asking, I wanted to run the
> idea past the list.
> 
> Rate control is not perfect, and on initial bringup it doesn't have
> many packets to work with so I thought it might still be useful to allow
> users to specify a particular rate for EAPOL packets.  Maybe using
> a socket ioctl so user-space (ie, supplicant/hostapd) can control it,
> for example.
minstrel and minstrel_ht always keep low rates in the rate retry chain
until enough higher rates have been proven to work.
I think adding an interface that allows user space to mess with the rate
selection of EAPOL packets is a bad idea - users will pretty much always
make worse rate decisions than the rate control module.

- Felix