|
Bugzilla – Full Text Bug Listing |
| Summary: | Assert failure in MinstrelHtWifiManager::GetLowestIndex | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | sebastien.deronne |
| Component: | wifi | Assignee: | Matías Richart <matis18> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ns-bugs |
| Priority: | P3 | ||
| Version: | ns-3.26 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
script to reproduce the issue
Patch to solve the issue. Patch to solve the issue v2 new proposed solution: fill in supported rates once beacon is received |
||
|
Description
sebastien.deronne
2017-01-21 04:34:01 UTC
Matias, could you have a look? The problem appears because the remote station supports VHT but there is no VHT MCS supported. There is always a default MCS supported but it is a HT (non VHT) MCS. The problem appears after fixes for bug 2532 (changeset 12385:54003ae0e2d4) because the remote station is set to support VHT but supported MCSs are not initialized. I attach a patch for minstrelHt that solves the issue. But, is it ok to have a remote station marked as vht supported but with no mcs available? Created attachment 2758 [details]
Patch to solve the issue.
Mark a group as supported only if there is at least one MCS supported inside the group.
(In reply to Matías Richart from comment #2) > The problem appears because the remote station supports VHT but there is no > VHT MCS supported. > > There is always a default MCS supported but it is a HT (non VHT) MCS. > > The problem appears after fixes for bug 2532 (changeset 12385:54003ae0e2d4) > because the remote station is set to support VHT but supported MCSs are not > initialized. > > I attach a patch for minstrelHt that solves the issue. > But, is it ok to have a remote station marked as vht supported but with no > mcs available? I do not understand, how can this have no VHT MCS supported? The user configure the nodes to be VHT machines running Minstrel HT, so I do not see anything wrong in the configuration itself. Sorry, but previous proposal generates another issue. It makes possible that no group (and so no MCS) is available and minstrel needs at least one MCS supported to work properly. I propose another patch to select an HT MCS when VHT is supported but only 1 MCS is available. This solution works assuming that there is always one default HT MCS. I'll test more extensibly the proposal but I think it works. Created attachment 2759 [details]
Patch to solve the issue v2
(In reply to sebastien.deronne from comment #4) > (In reply to Matías Richart from comment #2) > > The problem appears because the remote station supports VHT but there is no > > VHT MCS supported. > > > > There is always a default MCS supported but it is a HT (non VHT) MCS. > > > > The problem appears after fixes for bug 2532 (changeset 12385:54003ae0e2d4) > > because the remote station is set to support VHT but supported MCSs are not > > initialized. > > > > I attach a patch for minstrelHt that solves the issue. > > But, is it ok to have a remote station marked as vht supported but with no > > mcs available? > > I do not understand, how can this have no VHT MCS supported? > The user configure the nodes to be VHT machines running Minstrel HT, so I do > not see anything wrong in the configuration itself. It is not an issue of configuration. In this example, minstrel is called before association is finished and then m_operationalMcsSet in remoteWifiManager is not filled yet. For this cases a default MCS is used, which is pushed when WifiRemoteStationState is created. But this default MCS is an HT MCS. When misntrel looks for a VHT MCS does not find any. (In reply to Matías Richart from comment #7) > (In reply to sebastien.deronne from comment #4) > > (In reply to Matías Richart from comment #2) > > > The problem appears because the remote station supports VHT but there is no > > > VHT MCS supported. > > > > > > There is always a default MCS supported but it is a HT (non VHT) MCS. > > > > > > The problem appears after fixes for bug 2532 (changeset 12385:54003ae0e2d4) > > > because the remote station is set to support VHT but supported MCSs are not > > > initialized. > > > > > > I attach a patch for minstrelHt that solves the issue. > > > But, is it ok to have a remote station marked as vht supported but with no > > > mcs available? > > > > I do not understand, how can this have no VHT MCS supported? > > The user configure the nodes to be VHT machines running Minstrel HT, so I do > > not see anything wrong in the configuration itself. > > It is not an issue of configuration. > In this example, minstrel is called before association is finished and then > m_operationalMcsSet in remoteWifiManager is not filled yet. > For this cases a default MCS is used, which is pushed when > WifiRemoteStationState is created. > But this default MCS is an HT MCS. When misntrel looks for a VHT MCS does > not find any. Can't we envision to have a VHT MCS as default if VHT is supported? Since this is quite default configuration, why is the issue only seen in this scenario? (In reply to sebastien.deronne from comment #8) > (In reply to Matías Richart from comment #7) > > (In reply to sebastien.deronne from comment #4) > > > (In reply to Matías Richart from comment #2) > > > > The problem appears because the remote station supports VHT but there is no > > > > VHT MCS supported. > > > > > > > > There is always a default MCS supported but it is a HT (non VHT) MCS. > > > > > > > > The problem appears after fixes for bug 2532 (changeset 12385:54003ae0e2d4) > > > > because the remote station is set to support VHT but supported MCSs are not > > > > initialized. > > > > > > > > I attach a patch for minstrelHt that solves the issue. > > > > But, is it ok to have a remote station marked as vht supported but with no > > > > mcs available? > > > > > > I do not understand, how can this have no VHT MCS supported? > > > The user configure the nodes to be VHT machines running Minstrel HT, so I do > > > not see anything wrong in the configuration itself. > > > > It is not an issue of configuration. > > In this example, minstrel is called before association is finished and then > > m_operationalMcsSet in remoteWifiManager is not filled yet. > > For this cases a default MCS is used, which is pushed when > > WifiRemoteStationState is created. > > But this default MCS is an HT MCS. When misntrel looks for a VHT MCS does > > not find any. > > Can't we envision to have a VHT MCS as default if VHT is supported? I think we can. I'll check if the standard say something about default rates when VHT is supported. > Since this is quite default configuration, why is the issue only seen in > this scenario? It is also seen in rate-adaptation-distance example if you change the standard to ac. But it does not happen in minstrel-ht-wifi-manager-example because it uses adhoc mode. (In reply to Matías Richart from comment #9) > (In reply to sebastien.deronne from comment #8) > > (In reply to Matías Richart from comment #7) > > > (In reply to sebastien.deronne from comment #4) > > > > (In reply to Matías Richart from comment #2) > > > > > The problem appears because the remote station supports VHT but there is no > > > > > VHT MCS supported. > > > > > > > > > > There is always a default MCS supported but it is a HT (non VHT) MCS. > > > > > > > > > > The problem appears after fixes for bug 2532 (changeset 12385:54003ae0e2d4) > > > > > because the remote station is set to support VHT but supported MCSs are not > > > > > initialized. > > > > > > > > > > I attach a patch for minstrelHt that solves the issue. > > > > > But, is it ok to have a remote station marked as vht supported but with no > > > > > mcs available? > > > > > > > > I do not understand, how can this have no VHT MCS supported? > > > > The user configure the nodes to be VHT machines running Minstrel HT, so I do > > > > not see anything wrong in the configuration itself. > > > > > > It is not an issue of configuration. > > > In this example, minstrel is called before association is finished and then > > > m_operationalMcsSet in remoteWifiManager is not filled yet. > > > For this cases a default MCS is used, which is pushed when > > > WifiRemoteStationState is created. > > > But this default MCS is an HT MCS. When misntrel looks for a VHT MCS does > > > not find any. > > > > Can't we envision to have a VHT MCS as default if VHT is supported? > > I think we can. I'll check if the standard say something about default rates > when VHT is supported. > > > Since this is quite default configuration, why is the issue only seen in > > this scenario? > > It is also seen in rate-adaptation-distance example if you change the > standard to ac. But it does not happen in minstrel-ht-wifi-manager-example > because it uses adhoc mode. Then I think regression should be extended in order cover this case. (In reply to sebastien.deronne from comment #10) > (In reply to Matías Richart from comment #9) > > (In reply to sebastien.deronne from comment #8) > > > (In reply to Matías Richart from comment #7) > > > > (In reply to sebastien.deronne from comment #4) > > > > > (In reply to Matías Richart from comment #2) > > > > > > The problem appears because the remote station supports VHT but there is no > > > > > > VHT MCS supported. > > > > > > > > > > > > There is always a default MCS supported but it is a HT (non VHT) MCS. > > > > > > > > > > > > The problem appears after fixes for bug 2532 (changeset 12385:54003ae0e2d4) > > > > > > because the remote station is set to support VHT but supported MCSs are not > > > > > > initialized. > > > > > > > > > > > > I attach a patch for minstrelHt that solves the issue. > > > > > > But, is it ok to have a remote station marked as vht supported but with no > > > > > > mcs available? > > > > > > > > > > I do not understand, how can this have no VHT MCS supported? > > > > > The user configure the nodes to be VHT machines running Minstrel HT, so I do > > > > > not see anything wrong in the configuration itself. > > > > > > > > It is not an issue of configuration. > > > > In this example, minstrel is called before association is finished and then > > > > m_operationalMcsSet in remoteWifiManager is not filled yet. > > > > For this cases a default MCS is used, which is pushed when > > > > WifiRemoteStationState is created. > > > > But this default MCS is an HT MCS. When misntrel looks for a VHT MCS does > > > > not find any. > > > > > > Can't we envision to have a VHT MCS as default if VHT is supported? > > > > I think we can. I'll check if the standard say something about default rates > > when VHT is supported. > > > > > Since this is quite default configuration, why is the issue only seen in > > > this scenario? > > > > It is also seen in rate-adaptation-distance example if you change the > > standard to ac. But it does not happen in minstrel-ht-wifi-manager-example > > because it uses adhoc mode. > > Then I think regression should be extended in order cover this case. I agree. Regarding which rate should we use I found this in the standard (Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 4: Enhancements for Very High Throughput for Operation in Bands below 6 GHz): Change the last paragraph of 9.7.5.3 as follows: If the BSSBasicRateSet parameter, the BSSBasicMCSSet parameter, and the BSS basic VHT-MCS and NSS set are empty (e.g., a scanning STA that is not yet associated with a BSS), the frame shall be transmitted in a non-HT PPDU using one of the mandatory PHY rates. I think we are in this case. What do you think? Indeed, and I guess the same applies for HT? I'll summarize my findings: The bug reported here is generated because a STA which supports VHT wants to transmit an Association Request to an AP which also supports VHT. MinstrelHt tries to send the frame with a VHT-MCS but does not found any VHT-MCS in the operationalMcsSet and fails. According to the standard if all rate sets (rate, ht and vht) are empty, the STA shall use a "mandatory PHY rate". Here I found 2 issues. - In NS3, the basicRateSet and the basicMcsSet are never empty because at initialization a "default rate" is pushed. It is not clear to me if this is correct and the implications of changing it. - However, in this case I think the sets shouldn't be empty. They should be filled with the supported rates received in the Beacon. The same way that it is done when we receive a probe response. Do you agree? (In reply to Matías Richart from comment #13) > I'll summarize my findings: > > The bug reported here is generated because a STA which supports VHT wants to > transmit an Association Request to an AP which also supports VHT. > MinstrelHt tries to send the frame with a VHT-MCS but does not found any > VHT-MCS in the operationalMcsSet and fails. > > According to the standard if all rate sets (rate, ht and vht) are empty, the > STA shall use a "mandatory PHY rate". > > Here I found 2 issues. > > - In NS3, the basicRateSet and the basicMcsSet are never empty because at > initialization a "default rate" is pushed. It is not clear to me if this is > correct and the implications of changing it. No idea, I saw some bugs in the past if this is not present so I would keep it for now. > > - However, in this case I think the sets shouldn't be empty. They should be > filled with the supported rates received in the Beacon. The same way that it > is done when we receive a probe response. Do you agree? Yes, it sounds incorrect that we do not fill supported modes upon beacon reception. Created attachment 2768 [details]
new proposed solution: fill in supported rates once beacon is received
Based on previous discussions, I prepared a new patch that fills in supported rates once beacon is received. Matias, do you agree with this (possibly) final patch?
(In reply to sebastien.deronne from comment #15) > Created attachment 2768 [details] > new proposed solution: fill in supported rates once beacon is received > > Based on previous discussions, I prepared a new patch that fills in > supported rates once beacon is received. Matias, do you agree with this > (possibly) final patch? I agree Fixed in changeset 12594:8076e0b00253 |