Skip to content

Avoid legacy STAs crashing simulations when using SpectrumWifiPhy

Davide Magrin requested to merge DvdMgr/ns-3-dev:spectrumwifiphy-legacy into master

It looks like the presence of legacy STAs is not handled kindly by SpectrumWifiPhy. If I change wifi-mixed-network.cc to use Spectrum instead of Yans, the last experiment (consisting in a mixed network comprised of HT and non-HT STAs) crashes with the following error and stack trace:

Run: Mixed HT/non-HT
	 enableErpProtection=0
	 erpProtectionMode=Cts-To-Self
	 enableShortSlotTime=0
	 enableShortPhyPreamble=0
	 apType=WIFI_STANDARD_80211n_2_4GHZ
	 nWifiB=0
	 bHasTraffic=0
	 nWifiG=1
	 gHasTraffic=0
	 nWifiN=1
	 nHasTraffic=1
aborted. cond="it == m_phyEntities.end ()", msg="Unsupported Wi-Fi modulation class", +1.006004041s 0 file=../src/wifi/model/wifi-phy.cc, line=881
terminate called without an active exception

Program received signal SIGABRT, Aborted.
0x00007ffff55fbd22 in raise ()
   from /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/libc.so.6
(gdb) where
#0  0x00007ffff55fbd22 in raise ()
   from /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/libc.so.6
#1  0x00007ffff55e5862 in abort ()
   from /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/libc.so.6
#2  0x00007ffff59a6802 in __gnu_cxx::__verbose_terminate_handler ()
    at /build/gcc/src/gcc/libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x00007ffff59b2c8a in __cxxabiv1::__terminate (handler=<optimized out>)
    at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:48
#4  0x00007ffff59b2cf7 in std::terminate ()
    at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:58
#5  0x00007ffff7a345cb in ns3::WifiPhy::GetPhyEntity (this=0x5555556761d0, 
    modulation=ns3::WIFI_MOD_CLASS_HT) at ../src/wifi/model/wifi-phy.cc:881
#6  0x00007ffff7ac0633 in ns3::SpectrumWifiPhy::StartRx (this=0x5555556761d0, 
    rxParams=...) at ../src/wifi/model/spectrum-wifi-phy.cc:382
#7  0x00007ffff7acd49f in ns3::WifiSpectrumPhyInterface::StartRx (
    this=0x5555556767d0, params=...)
    at ../src/wifi/model/wifi-spectrum-phy-interface.cc:109
#8  0x00007ffff745d627 in ns3::MultiModelSpectrumChannel::StartRx (
    this=0x5555555a5410, params=..., receiver=...)
    at ../src/spectrum/model/multi-model-spectrum-channel.cc:355
#9  0x00007ffff7460897 in ns3::MakeEvent<void (ns3::MultiModelSpectrumChannel::*)(ns3::Ptr<ns3::SpectrumSignalParameters>, ns3::Ptr<ns3::SpectrumPhy>), ns3::MultiModelSpectrumChannel*, ns3::Ptr<ns3::SpectrumSignalParameters>, ns3::Ptr<ns3::SpectrumPhy> >(void (ns3::MultiModelSpectrumChannel::*)(ns3::Ptr<ns3::SpectrumSignalParameters>, ns3::Ptr<ns3::SpectrumPhy>), ns3::MultiModelSpectrumChannel*, ns3::Ptr<ns3::SpectrumSignalParameters>, ns3::Ptr<ns3::SpectrumPhy>)::EventMemberImpl2::Notify() (
    this=0x555555594fa0) at ./ns3/make-event.h:436
#10 0x00007ffff5dbd851 in ns3::EventImpl::Invoke (this=0x555555594fa0)
    at ../src/core/model/event-impl.cc:51
#11 0x00007ffff5dc2fc1 in ns3::DefaultSimulatorImpl::ProcessOneEvent (
    this=0x555555637d00) at ../src/core/model/default-simulator-impl.cc:151
#12 0x00007ffff5dc33a7 in ns3::DefaultSimulatorImpl::Run (this=0x555555637d00)
    at ../src/core/model/default-simulator-impl.cc:204
#13 0x00007ffff5dbe6d4 in ns3::Simulator::Run ()
    at ../src/core/model/simulator.cc:176
#14 0x00005555555691a4 in Experiment::Run (this=0x7fffffffe3d7, params=...)
    at ../examples/wireless/wifi-mixed-network.cc:297
#15 0x000055555556b392 in main (argc=1, argv=0x7fffffffe6a8)
    at ../examples/wireless/wifi-mixed-network.cc:512

Checkout this branch to quickly reproduce the error above by running ./waf --run wifi-mixed-network.

This happens because a legacy STA fails to find a usable PhyEntity to decode a message sent with an unsupported modulation class, and an abort is thrown by WifiPhy::GetPhyEntity. This case actually seems to be handled properly in StartReceivePreamble at the end of the StartRx function, however this crash happens before we can get to that point, during the checks on sensitivity and overlap with the primary 20 MHz channel. The proposed patch makes us not crash in this occasion.

Note that, with this change, StartReceivePreamble will not be called for these packets. Also, this TODO in StartReceivePreamble seems like it could be related to this situation, in which it may be desirable to still extract data from the preamble:

//TODO find a fallback PHY for receiving the PPDU (e.g. 11a for 11ax due to preamble structure)

Merge request reports