dce-iperf Linux stack GetAddress derefferences null ptr

[ParthPratim]

• ns3 version (cat $NS3FOLDER/VERSION or the commit hash): ns-3.34
• DCE version (git log|head -n1): c0afe69
• Operating system/version (lsb_release -a): Ubuntu-(16.04, 20.04)
• Libc version (ldd -v): ld-(2.23, 2.31)
• compiler version (gcc -v/g++ -v/clang -v/clang++ -v): (5.40 , 9.3.0)

Description of the problem

The dce-iperf script works fine when using the InternetStackHelper implemented in ns-3-dev, but fails with the below error when using the LinuxStackHelper implemented in DCE.

assert failed. cond="m_ptr", msg="Attempted to dereference zero pointer", +0.000000000s -1 file=/home/parth27/project/template/bake/build/include/ns3-dev/ns3/ptr.h, line=630

Steps to reproduce

Run the following command to enable the Linux stack in dce-iperf

./waf --run "dce-iperf --stack=linux"

Issue Location in Code

The issue is with the line :

ns-3-dce/example/dce-iperf.cc

Line 119 in 4bca774

Ipv4Address serverAddress = ipv4Server->GetAddress (1, 0).GetLocal ();

The Ipv4Linux::GetAddress() implementation cannot seem to reference the 1st index as it exceeds the size of the m_interfaces stack.

[ParthPratim]

ns-3-dce/example/dce-iperf.cc

Lines 118 to 122 in 4bca774

	Ptr<Ipv4> ipv4Server = nodes.Get (1)->GetObject<Ipv4> ();
	Ipv4Address serverAddress = ipv4Server->GetAddress (1, 0).GetLocal ();
	serverAddress.Print (serverIp);
	dce.AddArgument (serverIp.str());

To find a quick fix, I commented out the serverIp string computation code segment, and then replaced the line 122, with the actual server IP address i.e 10.1.1.2.
And it worked fine with accurate iperf reports in the file-* folder.

So, As a temporary fix we can have this patch.

But, I was thinking of why Ipv4's GetAddress(...) function works differently in LinuxStackHelper as compared to InternetStackHelper.

After a bit of debugging, I arrived at this conclusion.

The Assign() [1] call of Ipv4InterfaceContainer, calls the AddInterface of the Ipv4 protocol implementation, which in case of LinuxStackHelper, maps to Ipv4Linux::AddInterface() of DCE, and it's implementation was similar to how Ipv4L3Protocol works, the only difference is ns-3's implementation maintains a reverse map from interface-device => interface's-stack-index, for accessing later in GetInterfaceForDevice(). So, now since everything is the same, there has to be something different in the initial m_interface stack.

ns-3-dce/helper/linux-stack-helper.cc

Lines 62 to 76 in 4bca774

	void
	LinuxStackHelper::Install (Ptr<Node> node)
	{
	#ifdef KERNEL_STACK
	Ipv4Linux::InstallNode (node);
	#if 0
	// Set routing
	Ptr<Ipv4> ipv4 = node->GetObject<Ipv4> ();
	Ptr<Ipv4RoutingProtocol> ipv4Routing = m_routing->Create (node);
	ipv4->SetRoutingProtocol (ipv4Routing);
	#endif
	Ipv6Linux::InstallNode (node);
	#endif
	}

The actual difference was between the Install function of LinuxStackHelper and InternetStackHelper[2]. In InternetStackHelper we also aggregate a Ipv4L3Protocol object[3], which goes on to call Ipv4L3Protocol::NotifyNewAggregate (), and further Ipv4L3Protocol::SetNode (Ptr<Node> node), which will further call Ipv4L3Protocol::SetupLoopback (void), which will add an additional LoopbackNetDevice to the Ipv4 interfaces list m_interfaces here [4]. And this is why the size of m_interfaces is 2, and thus accessing the 1th index in the stack is possible, and doesn't throw a null ptr dereference error.

[1] : https://www.nsnam.org/doxygen/ipv4-address-helper_8cc_source.html#l00135
[2] : https://www.nsnam.org/doxygen/internet-stack-helper_8cc_source.html#l00292
[3] : https://www.nsnam.org/doxygen/internet-stack-helper_8cc_source.html#l00304
[4] : https://www.nsnam.org/doxygen/ipv4-l3-protocol_8cc_source.html#l00372

This is probably the cause behind this issue.

[tomhenderson]

Suggested patch to fix: #126