[Ns-bugs] [Bug 940] New: AODV fails to set up a correct path

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=940

           Summary: AODV fails to set up a correct path
           Product: ns-3
           Version: ns-3.8
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: routing
        AssignedTo: ns-bugs at isi.edu
        ReportedBy: c.facchini at gmail.com
   Estimated Hours: 0.0


Created an attachment (id=916)
 --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=916)
Simulation scripts reproducing the bug

Important notes:
* this behavior does not occur always: specifically, only for some seeds AODV
fails to establish a route.
* Also, I am not sure if this bug is related to bug 879 (in that bug TCP is
used, whereas here UDP is used).

I saw that AODV cannot establish a correct route for the following
configuration:
* OnOffApplication + UDP
* WifiAdHoc multi-hop network w/ chain topology: OnOffApp on 1st node,
PacketSink on n-th node
* ~200 seconds of simulation

Here's an excerpt of a gdb session:
Breakpoint 6, ns3::UdpSocketImpl::DoSendTo (this=0x80b7a00, p=..., dest=...,
port=21) at ../src/internet-stack/udp-socket-impl.cc:430
430          route = ipv4->GetRoutingProtocol ()->RouteOutput (p, header, oif,
errno_); 
(gdb) bt
#0  ns3::UdpSocketImpl::DoSendTo (this=0x80b7a00, p=..., dest=..., port=21) at
../src/internet-stack/udp-socket-impl.cc:431
#1  0xb76a6bea in ns3::UdpSocketImpl::DoSend (this=0x80b7a00, p=...) at
../src/internet-stack/udp-socket-impl.cc:271
#2  0xb76a6ee8 in ns3::UdpSocketImpl::Send (this=0x80b7a00, p=..., flags=0) at
../src/internet-stack/udp-socket-impl.cc:249
#3  0xb75d2ce9 in ns3::Socket::Send (this=0x80b7a00, p=...) at
../src/node/socket.cc:112
#4  0xb77e4e2e in ns3::OnOffApplication::SendPacket (this=0x80aa7b8) at
../src/applications/onoff/onoff-application.cc:240
#5  0xb77e2f14 in Notify (this=0x80a4f78) at debug/ns3/make-event.h:94
#6  0xb745694a in ns3::EventImpl::Invoke (this=0x80a4f78) at
../src/simulator/event-impl.cc:37
#7  0xb74764aa in ns3::DefaultSimulatorImpl::ProcessOneEvent (this=0x807add0)
at ../src/simulator/default-simulator-impl.cc:128
#8  0xb747650a in ns3::DefaultSimulatorImpl::Run (this=0x807add0) at
../src/simulator/default-simulator-impl.cc:158
#9  0xb745f915 in ns3::Simulator::Run () at ../src/simulator/simulator.cc:173
#10 0x08052858 in main (argc=2, argv=0xbffff3c4) at ../scratch/aodv.cc:138
(gdb) n
431          if (route != 0)
(gdb) p route
$6 = {
  m_ptr = 0x80b5eb0
}
(gdb) p/x (*route->m_ptr)
$7 = {
  <ns3::SimpleRefCount<ns3::Ipv4Route, ns3::empty,
ns3::DefaultDeleter<ns3::Ipv4Route> >> = {
    <ns3::empty> = {<No data fields>}, 
    members of ns3::SimpleRefCount<ns3::Ipv4Route, ns3::empty,
ns3::DefaultDeleter<ns3::Ipv4Route> >: 
    m_count = 0x1
  }, 
  members of ns3::Ipv4Route: 
  m_dest = {
    m_address = 0xa000005
  }, 
  m_source = {
    m_address = 0x66666666
  }, 
  m_gateway = {
    m_address = 0x7f000001
  }, 
  m_outputDevice = {
    m_ptr = 0x80a26d8
  }
}

By translating the addresses, it is possible to see that the destination is
10.0.0.5 (correct), the source is 102.102.102.102 (not correct), and the
gateway is 127.0.0.1 (not correct).

I have attached a simulation script that reproduces the bug (in my case using
--RngRun=10 turns on the bug).
To find a "bug-enabling" seed one could use a quick'n'dirty for-loop in bash
(hitting ctrl-c whenever packet are received):
for i in $(seq 1 2000) ; do ./waf --command-template="%s --RngRun=$i" --run
"scratch/aodv" ; done

-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.