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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Tue, Sep 10, 2013 at 12:40 AM, Ben Greear <[email protected]> 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.
On Tue, 2013-09-10 at 14:47 +0530, Krishna Chaitanya wrote:
> On Tue, Sep 10, 2013 at 4:40 AM, Ben Greear <[email protected]> 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
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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
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
On Tue, Sep 10, 2013 at 4:40 AM, Ben Greear <[email protected]> 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?
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
On 09/09/2013 12:15 PM, Krishna Chaitanya wrote:
> On Tue, Sep 10, 2013 at 12:40 AM, Ben Greear <[email protected]> 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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com