Always send management frames at MCS-0??
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 8 lines · 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?
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.
Quoted 6 lines · Krishna Chaitanya
Quoted 5 lines · 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.
Quoted 9 lines
Quoted 3 lines
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 2 lines · Ben Greear
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?
Quoted 6 lines · Krishna Chaitanya
Quoted 2 lines · Ben Greear
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
Quoted 6 lines · 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?
If this is with ath9k_rate_control, then it is a known bug:
https://bugzilla.redhat.com/show_bug.cgi?id=927191
Sujith
Quoted 10 lines · Sujith Manoharan
Quoted 6 lines · 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?
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 17 lines · Ben Greear
Quoted 10 lines · Sujith Manoharan
Quoted 6 lines · 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?
If this is with
ath9k_rate_control, then it is a known bug:
https://bugzilla.redhat.com/show_bug.cgi?id=927191I'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.
Quoted 5 lines
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