Bugzilla – Bug 2826
Management frames should be sent using the lowest basic rate
Last modified: 2018-03-02 17:47:38 UTC
I wrote a very simple script using 802.11ac with constant rate VHT MCS 9 and I enabled active probing, then I hit the following assert: assert failed. cond="duration.IsPositive ()", msg="Please provide test case to maintainers if this assert is hit.", file=../src/wifi/model/mac-low.cc, line=1876 libc++abi.dylib: terminating If I use another rate algorithm, such as Ideal or MinstrelHt, assert is not hit. Just looking at traces, I can see Ideal and MinstrelHt sent the probe request/response frames at the lowest basic rate, while Constant sends at the selected MCS value. If I look at Wireshark captures with real 802.11n/ac devices, Ideal and MinstrelHt provide the correct behavior. I guess we should enforce that constant rate manager does not use those constant data rate for management frames. I will further investigate how to fix this.
Note that with fix for bug 2827, the assert is no longer hit. Anyway, even though the rate chosen for management frames is let to the implementation, I saw most implementation using basic rates (actually the lowest one). I suggest the management response frames to be sent at a basic rate not higher than the rate used in the management request frame. Question is still to be asked for unicast management request frames, such as association or ADDBA requests. I would send them at the lowest basic rate, but I am not sure this is always the case in most implementations. Any thoughts on this?
As a side note, I think I read somewhere in linux driver discussions that it is safer to send those frame at the lowest basic rate, but that this is not mandatory by the standard. I still need to further check this on a real setup (I will base myself on QCA-ath9k chipsets which are quite widely used).
I can see in mac80211 that management frames do not use rate control, so this should even not be dependent on the wifi manager that is being used. I suggest to add this logic in the wifi station manager: - if not management: ask rate to wifi rate manager - if management: select the lowest basic rate
Created attachment 3067 [details] proposed patch I made a patch that always selects the lowest basic rate for management frames. This is more an implementation choice rather than a standard rule (there is no rule for that in the standard). This is also inspired from how the Linux stack works. Of course, not all 802.11 manufacturers follow this rule. If one wants to change this behavior, either we add an attribute or we let this to the user. Note that devices-mesh-dot11s-regression needs to be rescanned. All other tests are passing.
(In reply to sebastien.deronne from comment #4) > Created attachment 3067 [details] > proposed patch > > I made a patch that always selects the lowest basic rate for management > frames. > > This is more an implementation choice rather than a standard rule (there is > no rule for that in the standard). This is also inspired from how the Linux > stack works. Of course, not all 802.11 manufacturers follow this rule. If > one wants to change this behavior, either we add an attribute or we let this > to the user. > > Note that devices-mesh-dot11s-regression needs to be rescanned. All other > tests are passing. I'm fine with the proposed patch but this behavior should be documented at least in a comment but ideally somewhere suitable in the .rst documentation also.
Tom, OK, I will update both.
Pushed in changeset 13357:ffdee425b739