Bugzilla – Bug 1911
AODV can not work on nodes with more than one NetDevice
Last modified: 2016-05-06 14:28:02 EDT
It may be a bug or a feature. The problem is that AODV can be installed on a non-WiFi network, but then it doesn't work.
The problem has been raised by an user, see:
In Aodv, NotifyInterfaceUp there is the following statement:
// Allow neighbor manager use this interface for layer 2 feedback if possible
Ptr<WifiNetDevice> wifi = dev->GetObject<WifiNetDevice> ();
if (wifi == 0)
Ptr<WifiMac> mac = wifi->GetMac ();
if (mac == 0)
mac->TraceConnectWithoutContext ("TxErrHeader", m_nb.GetTxErrorCallback ());
m_nb.AddArpCache (l3->GetInterface (i)->GetArpCache ());
which may be a hint.
Things to tests:
1) AODV on a non-WiFi interface (e.g., csma), and
2) AODV on a no-ARP interface (GetArpCache could return null).
Created attachment 1834 [details]
An example program showing the bug.
The p2p link is used "as intended", but RREP are not forwarded (the intermediate node doesn't seems to be receiving the RREP at all).
The problem is a bit more complex than I thought.
AODV opens an UDP socket for each interface:
// Create a socket to listen only on this interface
Ptr<Socket> socket = Socket::CreateSocket (GetObject<Node> (),
NS_ASSERT (socket != 0);
socket->SetRecvCallback (MakeCallback (&RoutingProtocol::RecvAodv, this));
int ret = socket->Bind (InetSocketAddress (Ipv4Address::GetAny (), AODV_PORT));
socket->BindToNetDevice (l3->GetNetDevice (i));
Any interface other than the first one will fail to open the socket, because the address is already in use.
As a matter of fact, it's a bad idea to open a socket on an "any" interface and then bind it to a NetDevice...
A possible solution is to open two sockets for each interface, one on the unicast address and one on the subnet-broadcast.
Note: this issue may be present in other protocols, as once upon a time we did not check that an n address was already in use, so the trick (bind to "any" address and then bind to the NetDevice) was working.
Created attachment 1835 [details]
This seems to work as intended.
I just did a quick test, no valgrind.
The regression test fails, I didn't check why.
Comment on attachment 1835 [details]
Always check the pcap before singing victory...
Created attachment 1836 [details]
All tests passed.
Example program, valgrind, examples, regression... everything.
I am OK with the patch but some example/regression test/documentation of how this works should also be added.
In general, it may be nice to add an example with a trivial configuration such as:
n0 <--- CSMA ---> n1 <--WiFi --> n2
and configure it to use different MANET routing protocols (OLSR, AODV, DSDV, DSR) via command-line argument switch, such as manet-routing-compare, and check that routing works between n0 and n2, then add the example to the regression tests multiple times, one for each option.
pushed in changeset: 10949:751e327b3632
I'll add an example as soon as I have the green light from the author (or I'll have made one anew).
For the records, the last commit didn't include all the intended changes.
Masahiro Rikiso found it and reported here: https://groups.google.com/forum/#!topic/ns-3-users/uOt_rI9azUE
Pushed the proper code in changeset: 12102:8583bcb611ef