Bugzilla – Bug 2838
ht-wifi-network crashes with RTS/CTS enabled and frequency set to 2.4GHz
Last modified: 2018-01-13 06:19:50 UTC
This was reported in the user group: https://groups.google.com/forum/#!topic/ns-3-users/DkEV3KA5RX8 To reproduce: 1/ add this line to ht-wifi-network script file: Config::SetDefault ("ns3::WifiRemoteStationManager::RtsCtsThreshold", StringValue ("0")); 2/ run: ./waf --run "ht-wifi-network --frequency=2.4"
I had a look, the problem is because the selected mode for the CTS by the transmitter of the RTS frame (used to compute the duration field) is 6 Mbit/s whereas the selected mode to transmit the CTS is 1 Mbit/s. At that moment, the association is not yet done and thus the transmitter of the CTS frame only has 1 Mbit/s in its basic rate set. To go further, I should first check what is the correct rate used to transmit CTS frames by 802.11n stations operating at 2.4 GHz, even though I strongly suspect the answer here is 6 Mbit/s. I also would like to check which rate is assumed for the CTS response by the RTS initiator when computing the duration field. If somebody already has the answers, he is welcome :-)
The IEEE 802.11-2016 states, in sub-section 10.7.6.5.2 (Selection of a rate or MCS) of 10.7.6.5 (Rate selection for control response frames), that " If a CTS or Ack frame is carried in a non-HT PPDU, the primary rate is defined to be the highest rate in the BSSBasicRateSet parameter that is less than or equal to the rate (or non-HT reference rate; see 10.7.10) of the previous frame. If no rate in the BSSBasicRateSet parameter meets these conditions, the primary rate is defined to be the highest mandatory rate of the attached PHY that is less than or equal to the rate (or non-HT reference rate; see 10.7.10) of the previous frame. " Section 10.7.10 gives the conversion rules from HT/VHT MCS (or reference non-HT basin to non-HT basic rate, and, as you very well suspected the lowest rate in the list is 6 Mbps. In addition, Table 17-20 indicates that, for OFDM with 20 MHz channel spacing, 6, 12, and 24 are mandatory rates for Rx and Tx. When merging these three points, if the 6 Mbps was selected for the RTS (irrespective of the BSSBasicRateSet) and that the other STA managed to decode it, it is an OFDM capable STA and should thus respond with 6 Mbps and not 1 Mbps.
Rediet, I think I have a fix for this, I am testing if no regression is introduced.
Created attachment 2986 [details] proposed patch to fix The solution is to remove the default mode/MCS, then in that case the basic set is empty at that moment and it follows the rule from the standard as you mentioned: "If no rate in the BSSBasicRateSet parameter meets these conditions, the primary rate is defined to be the highest mandatory rate of the attached PHY that is less than or equal to the rate (or non-HT reference rate; see 10.7.10) of the previous frame." I have just a mesh regression test that is failing: devices-mesh-dot11s-regression (pmp-regression) It is failing because it compares the pcap files, and with those changes the basic rate set in the information element is empty whereas before it was containing the default mode. IMO it is acceptable to rescan the pcap files, but I am not a mesh expert so any comment is welcome.
> > It is failing because it compares the pcap files, and with those changes the > basic rate set in the information element is empty whereas before it was > containing the default mode. IMO it is acceptable to rescan the pcap files, > but I am not a mesh expert so any comment is welcome. I had a look at these mesh traces, and agree that the only difference is as you described, so I suggest to update the traces and proceed: ./test.py -u -s devices-mesh-dot11s-regression
Tom, OK, thanks for your feedback.
Pushed in changeset 13252:70f7b8f82aaf